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
|
