Post #100,108
5/3/03 12:47:45 PM
|
Additionally...
I am a lot more impressed with arguments like, "I tried language Foo for 5 years, and here are the exact problems with it" as opposed to ones like, "I think language Foo is a bad thing, because this might happen, and this might happen, and this might be a problem."
:-)
Regards,
-scott anderson
"Welcome to Rivendell, Mr. Anderson..."
|
Post #100,125
5/3/03 3:51:40 PM
8/21/07 6:28:02 AM
|
That's the C++ propaganda
the whole thing is based on fear (of mis-using a pointer).
That's the only kind of error the type checker/template madness helps with.
Here's a lovely little canonical example. Much is made of using a template to implement a max function rather than the old macro.
template<class T>
const T& max(const T& t1, const T& t2) { return t1 > t2 ? t1 : t2; }
now try it with:
int i = 7;
long j = 5;
max(i,j); // compile error WTF? This is useless.
they both have to be the same type.
Things I want to compare are hardly ever the same type (due to odd choices in int, long, short, char, unsigned variants, etc...
And templates don't do type promotion. So you'll have to cast (which is a great way to shoot yourself in the foot - like a certain rocket telemetry system showed).
Or use the macro - which does the correct promotion (like you would expect).
const char * type(int i) { return "int"; }
const char * type(long i) { return "long"; }
cout << "max " << type(i > j ? i : j) << " " << (i > j ? i : j) << endl;
// prints "max long 7"
So templates are still stupid.
"Packed like lemmings into shiny metal boxes.
Contestants in a suicidal race."
- Synchronicity II - The Police
|
Post #100,375
5/5/03 2:48:10 PM
|
Wrong usage
template <class T1, class T2>
T1 max(T1 a, T2 b) {
if (a > b) return a;
return b;
}
int main(int argc, char *argv[])
{
float v1 = 10;
int v2 = 20;
max(v1, v2);
}
And, I am sure that someone who knows templates better than me can figure out the return value problem.
--
Want to be original? Start with a great template!
|
Post #100,379
5/5/03 3:29:08 PM
8/21/07 6:33:56 AM
|
Return value problem
you nailed it - how do you tell which type, T1 or T2 should be the return value? And how do you write the code such that the correct precision is maintained in the result?
Answer: you specialize the template - to the point that you've fully specified all possible overload sequences and then the template has shown itself to be worthless in this case (except for the everything-is-a-T case).
you could try this:
template<class T>
double max(double x1, T x2) // if there's one double they're all double
{
return x1 > x2 ? x1 : x2;
}
to save some work - but you'll get an ambiguity if you try max(double, double) between the max is all T's and max T1 T2 definitions.
Thus, C++ can help you expand work to fill all available time with no trouble at all.
Or you could use a macro.
"Packed like lemmings into shiny metal boxes.
Contestants in a suicidal race."
- Synchronicity II - The Police
|
Post #100,408
5/5/03 7:30:55 PM
|
I'll take a look for the solution for ret value
In the meantime, have a fill of this: a guy at the place where I work uses templates to overload _integers_ with tracking code. He will then use those overloaded integers in the contexts wher he wants to collect stats. For the user, it's still an integer, slightly larger in memory. Stats collector has a thread to get snapshots and remember them.
This struck me as a very Smalltalk-ish thing to do. :)
--
Want to be original? Start with a great template!
|
Post #100,450
5/5/03 10:19:41 PM
|
Re: Return value problem
It's interesting - I've done most of my C++ coding in some numerical/mathematical context - needless to say, the occasion to use templates came up again and again - and then I'd think - no, the very fact that I'm thinking about this means these things are enough different to treat differently, and so forget this stupid template.
See, it's not really a template - it's a second, backdoor attempt to have a scalable type of data, since the objectness in the front door effort is a sort of fake.
Finally I'd accomplish making the differences manifest with overloading by hand - which no doubt is all the template is doing in the first place, and the code made much more sense.
-drl
|
Post #100,517
5/6/03 9:17:21 AM
|
In the end
you do need different implementations for different types, so "overloading by hand" is inevitable. It's nice to have compiler do it for you.
I agree that templates represent another, backdoor attempt at real type system, after virtual functions failed to deliver. I am beginning to think that templates are simply Smalltalk-style metadata, represented in many, many versions of generated code. Just like in Lisp one can implement lists with closures, the same way one can replace metadata with lots of generated code. To some extent. There have to be better statically-typed languages.
--
Want to be original? Start with a great template!
|
Post #100,689
5/7/03 5:13:57 AM
|
A better statically typed language - have you tried Haskell?
"good ideas and bad code build communities, the other three combinations do not"
- [link|http://archives.real-time.com/pipermail/cocoon-devel/2000-October/003023.html|Stefano Mazzocchi]
|
Post #100,949
5/8/03 3:15:36 PM
8/21/07 12:41:27 PM
|
Read the tutorials
it is somewhat related to the ML series IIRC, the most popular being OCAML I think.
There are some interesting ideas in there and I can think of two language research projects that are also working on similar typing ideas - one called slate which is being implemented in squeak, and the needle project.
The thing that keeps me from bothering to write code in languages like these is lack of platform interface support - ie, is there a bridge to most system routines I might want or a reasonably complete library availble. (for instance oberon was touted as being a great oo environment for awhile - but it had its own everything and always looke really ugly and alien on all the platforms I've seen it run on).
"Packed like lemmings into shiny metal boxes.
Contestants in a suicidal race."
- Synchronicity II - The Police
|
Post #100,998
5/8/03 7:32:39 PM
|
Today's link at /.
An [link|http://www.paulgraham.com/hp.html|article] on "hackers".
>>>>>>>>>>>>>>>>>>>
We need a language that lets us scribble and smudge and smear, not a language where you have to sit with a teacup of types balanced on your knee and make polite conversation with a strict old aunt of a compiler.
<<<<<<<<<<<<<<<<<<<
--
Want to be original? Start with a great template!
|
Post #100,551
5/6/03 1:09:49 PM
5/6/03 5:26:41 PM
|
Interesting example, Todd
template<class T>
const T& max(const T& t1, const T& t2) { return t1 > t2 ? t1 : t2; } I must say, I'm a bit confused by this, as what you've done by typing the parametters as const T& is using the C++ mechanism for enjoining the compiler from doing a type promotion on a parameter, then complaining that it won't do type promotions. If you want it to do type promotions, specify the template thus: template <class T> const T& max (T t1, T t2) { return t1 > t2 ? t1 : t2; } But wait, you'll complain, what if T is a BigAssClass type? Passing a BigAssClass object by value is not recommended, as its too big, and you don't want to load the stack with such a monstrosity. That's quite true, but then, you wouldn't want to convert a BigAssClass to an int (or float, or double, or whatever), either, would you? [edit: used the same name for the BigAssClass type...consistency, you know...] jb4
"We continue to live in a world where all our know-how is locked into binary files in an unknown format. If our documents are our corporate memory, Microsoft still has us all condemned to Alzheimer's."
Simon Phipps, SUN Microsystems
Edited by jb4
May 6, 2003, 05:26:41 PM EDT
|
Post #100,576
5/6/03 2:15:24 PM
|
Umm...
wouldn't that require that t1 and t2 be of the same type and return only that type?
(course, you could do a return of the address of the object, casted to a void pointer...then you could return either object, but that's just me).
|
Post #100,616
5/6/03 5:15:51 PM
8/21/07 6:38:46 AM
|
And what would you cast the void* back to afterwards?
"Packed like lemmings into shiny metal boxes.
Contestants in a suicidal race."
- Synchronicity II - The Police
|
Post #100,631
5/6/03 6:47:54 PM
|
Yeah, you'd have to test for the type...
or assign it to a base class pointer that the two types are dervived from.
Of course, there are cases were you'd have to the for type for your max macro.
sprintf("%d", max(long, float));
|
Post #100,644
5/6/03 9:15:43 PM
8/21/07 6:39:11 AM
|
Aaaaaahhhhhhh!
sprintf("%d", max(long, float));
Why don't you just juggle torches while you gas up your car? First, you're short an argument to sprintf - you forgot the destination buffer. Second, the xxxxf family (scanf, printf, and their variants), have no place in C++. Use strstreams. char buffer[50]; ostrstream ost(buffer,sizeof(buffer)); ost << (max(aLong, aFloat)) << ends;
"Packed like lemmings into shiny metal boxes.
Contestants in a suicidal race."
- Synchronicity II - The Police
|
Post #100,647
5/6/03 9:46:44 PM
|
*chuckle*
d00d, that was off the cuff. It wasn't meant to be code perfect - just to illustrate a problem with max.
Second, use stringstreams. strstreams are the old style char* stuff, iirc. You have to unfreeze any .str() you create via them...yuk.
|
Post #100,672
5/7/03 1:00:51 AM
8/21/07 6:39:47 AM
|
Oh, you illustrated several problems
max was the least of them.
Thanks for the tip on the updated streams. I can't say they're an improvement though.
Item 1: YTF did they blend istream and ostream in stringstream? Can you use it as a queue? Will it block on reads or throw an exception? We already have pipes for this stuff.
Item 2: The new version is written in terms of string. This is OK, but string does heap allocation all the time so for small buffers its likely to suck compared to stack memory. You'll note that in my code I don't need to call str or freeze as I already have the buffer. So it looks like streaming to a known memory location is no longer supported. So much for high performance code.
Item 3: You can construct one with no buffer (it'll use a string) or a const string&. Nifty. Suppose I want to stream into my own string. I'll miss WriteStream on: myString.
WTF are this people thinking?
"Packed like lemmings into shiny metal boxes.
Contestants in a suicidal race."
- Synchronicity II - The Police
|
Post #100,593
5/6/03 4:22:57 PM
8/21/07 6:38:33 AM
|
Your code should crash
returning a reference to a temporary stack variable like that. I'm assuming this was a copy paste error - its one that can crash your program with a memory access violation though (if you're lucky). Tell me again about the safety of the language and how it keeps you from screwing yourself. I must say, I'm a bit confused by this, as what you've done by typing the parametters as const T& is using the C++ mechanism for enjoining the compiler from doing a type promotion on a parameter, then complaining that it won't do type promotions. Funny, I thought I was employing the C++ mechanism for reducing stack growth. But wait, you'll complain, what if T is a BigAssClass type? Passing a BigAssType object by value is not recommended, as its too big, and you don't want to load the stack with such a monstrosity. That's quite true, but then, you wouldn't want to convert a BigAssObject to an int (or float, or double, or whatever), either, would you? Really? I can imagine all kinds of scenarios of BigAssOrderedType. Here's a good one - suppose I have 2DVector and 3DVector. It makes sense that I can promote a 2Dvector to a 3Dvector - and if I mixed them, I'd certainly like promotion to happen towards 3Dvector. So maybe I implement operator 3Dvector on 2Dvector (being careful not to implement operator 2Dvector on 3Dvector lest we end up in ambiguity hell). Boy, we've sure thought a lot about types without giving what the heck we're supposed to be doing a lick of thought. Thats why I think C++ is unredeemable shit. Working the type system consumes all available cycles and often - you still don't have an ironclad solution (like here). The bottom line in this scenario is clearly, passing classes by value is just not worth the trouble it causes and the feature ought not to be there at all. Yes C allows you to pass structs by value - no that wasn't a good idea. The smart thing to do would be to simply ignore the feature like Objective C did (objects only live on the heap - object references can live on the stack). The attempt to unify classes and structs was, in retrospect, a really bad choice.
"Packed like lemmings into shiny metal boxes.
Contestants in a suicidal race."
- Synchronicity II - The Police
|
Post #100,622
5/6/03 6:01:00 PM
|
My code does crash, but not as often as you think.
First, if you follow my posts, you'll know that my typing skills (such as they are) are nothing short of abyssmal. ;-) I must say, I'm a bit confused by this, as what you've done by typing the parametters as const T& is using the C++ mechanism for enjoining the compiler from doing a type promotion on a parameter, then complaining that it won't do type promotions.
Funny, I thought I was employing the C++ mechanism for reducing stack growth.
To a degree, that's true. But you have also enjoined the compiler from doing the standard promotions. Which is OK, but if you're going to do that, you need to be aware of the side effects. (I understand that Perl has similar syntatical quirks that will screw up the illiterati if they're not fully grokked.) Boy, we've sure thought a lot about types without giving what the heck we're supposed to be doing a lick of thought. I disagree. We have been spending a lot of time decising the kinds of operations we need to do on a BigAssClass, or a BigAssOrderedType. Your preceding paragraph specified what we want to be able to do. Now, given the tools available to do that, we start planning how to do it. If my tool set includes C++ , then I worry about how to manipulate the types to permit me to get where I want. If I have access to Python, or Objective C, then a whole different set of manipulations will have to occur. (If all I have is C# or Visual Basic, please put me out of my misery ASAP....) I will freely admit that the implementational issues that C++ presents are...unique...and and not always straightforward. But you will have a tough time convincing me that these other languages bandied about in this thread as panaceas to all the ills of programming ever foisted upon mankind are without their own set of problems, peculiarities, and pecadilloes. jb4
"We continue to live in a world where all our know-how is locked into binary files in an unknown format. If our documents are our corporate memory, Microsoft still has us all condemned to Alzheimer's."
Simon Phipps, SUN Microsystems
|
Post #100,624
5/6/03 6:04:08 PM
|
Re: My code does crash, but not as often as you think.
But you will have a tough time convincing me that these other languages bandied about in this thread as panaceas to all the ills of programming ever foisted upon mankind are without their own set of problems, peculiarities, and pecadilloes. Answer #1: especially if you never try them out. Answer #2: I don't think anyone is trying to convince you of that. What we are trying to convince you of is the fact that C++ has serious problems, much more so than other languages. Still waiting for you to respond to the two large posts that Todd and I put together for you, BTW. Regards,
-scott anderson
"Welcome to Rivendell, Mr. Anderson..."
|
Post #100,796
5/7/03 6:57:16 PM
|
Replies coming
Posts read, and comments pending. Hard to find a suitable time to respond in full under current workload (esp considering my typing skilz...;-) )
jb4
"We continue to live in a world where all our know-how is locked into binary files in an unknown format. If our documents are our corporate memory, Microsoft still has us all condemned to Alzheimer's."
Simon Phipps, SUN Microsystems
|
Post #100,642
5/6/03 8:37:38 PM
8/21/07 6:39:07 AM
|
Re: My code does crash, but not as often as you think.
We have been spending a lot of time decising the kinds of operations we need to do on a BigAssClass, or a BigAssOrderedType. Your preceding paragraph specified what we want to be able to do. Now, given the tools available to do that, we start planning how to do it.
Well, unfortunately, when you define that max function in terms of T, you know have to keep in the back of your mind the potential effects of calling max(SomethingYouDidntReallyThinkThatHardAbout,SomethingElseYouDidntReallyThinkThatHardAbout); IOW, that template mechanism paints with an infinitely broad brush and you now have to understand its exact expansion, along with expansions of any possible specializations you have (or your team mate wrote and didn't tell you about), and any automatic type conversion operators you've written along with any single argument constructurs you have. To illustrate this, allow me to tell you about a short little gig I had as a porting engineer. During a development cycle when everybody was working on windows (except me, 'cause I just don't do windows), I would check out the code every morning and spend hours trying to build it - fixing portability issues and sending out hate mail to the team about some of their stupid assumptions. One day I hit a compile error on something like: CustomString str = "foo"; ... return foo + "bar"; I looked up the developer and showed him the header for CustomString (this is before stl compiled anywhere other than Borland btw) and pointed out that there was no operator+ implemented on CustomString. He seemed perplexed because it worked fine on Windows. And so it did. As CustomString had an operator const char* defined, the MSString object had a ctor for const char*, an operator+, and an operator const char*. As we traced the execution we found that the compiler on windows had figured out it could construct a temp MSString (whatever they call it, I forget), do the operator+, then construct CustomString temp off the MSString's operator const char*. Something like that - but the type conversions/automatic operator calls were several layers deep and of course there is no MSString for unix. This lead me to conclude that the C++ type system is too complex for any human to predict what will happen for a given bit of code, and the introduction of a single function linking a couple types together and have far reaching unintended consequences on the system's overall behavior. Thus, I boldly make the statement "C++ doesn't scale".
"Packed like lemmings into shiny metal boxes.
Contestants in a suicidal race."
- Synchronicity II - The Police
|
