std/stl is the root to all evil
I think we have the classic case of a kid who can program hello world by himself or cut and paste NEHE code and now he thinks he is the shit.
Quote:
Such as reducing memory overhead from (4+4)*num_objects to log2(max_objects)*num_objects. In certain applications, a doubly-linked list can be had with one pointer (by storing prev XOR next); the pointer can be reduced to a few bits if allocator guarantees all nodes are consecutive.
Both this, and your rebuttal to my comment about std::string and strcat(), are valid situations where the STL's customization capabilities probably don't fit that specific situation ideally. My "such as" comment wasn't intended as "there is no such case" but rather to illicit a reply from C_Modest_God as to what situations he thought he needed that the STL couldn't provide (he may have had a specific one in mind that the STL could actually do; perhaps he just doesn't know about it?)
Quote:
I understand bpoint as saying STL is not good in all cases (viz. time-critical code); everyone is jumping on him as if he'd said "it should never be used and ideally banned from existence". Is the former interpretation so hard to accept?
The former interpretation isn't hard to accept at all, but everything I got (and the others that replied, it would seem) from bpoint's post indicated to me that he was advocating that it should never be used.
Quote:Original post by Anonymous Poster
I think we have the classic case of a kid who can program hello world by himself or cut and paste NEHE code and now he thinks he is the shit.
or a crusty old C programmer that won't accept change. If you want to keep using C go ahead, it is better for some things like old consoles and robotics. However there's no excuse for still using strcat on any modern hardware. Either continue using C or switch to C++, but please don't use some horride mix of both combined.
I just wanted to add one quick thing about the use of exceptions. (it was mentioned above somewhere) as being slow. There is hardly any overhead when using exceptions if the exception was not actually thrown. An basically, if you code thrown an exception something is going on that shouldn't be in which case an extra few milliseconds isn't going to kill you.
Obviously, this does imply that the author of the exception based code needs to understand exceptions and not use them in silly places which could easily result in slow code.
Moral of the story: Exceptions are a great help and something that your c++ programming is going to stereotype into something that slows down the app. That, however, would be an ignorant statement to make.
None of my comments are intended to me personal attacks, just wanted to expose that exceptions are good, use them!
Obviously, this does imply that the author of the exception based code needs to understand exceptions and not use them in silly places which could easily result in slow code.
Moral of the story: Exceptions are a great help and something that your c++ programming is going to stereotype into something that slows down the app. That, however, would be an ignorant statement to make.
None of my comments are intended to me personal attacks, just wanted to expose that exceptions are good, use them!
Quote:Original post by Jan Wassenberg
Wow, this is getting into another round of pointless C++ vs. C flameage.
Maybe we can take a step back and look at it like this. I understand bpoint as saying STL is not good in all cases (viz. time-critical code); everyone is jumping on him as if he'd said "it should never be used and ideally banned from existence". Is the former interpretation so hard to accept?
Actually, yes, it is.
Quote:Original post by bpoint
I _fully_ agree with the OP. STL is horrid, it's ugly... it's like a red-headed step-child. :)
He goes on in such a fashion never once stating any sort of qualifing remark about the STL having a place - only on and on about the shortcommings it has, and how unsafe C solutions are apparently superior - again, with no qualifing remarks about when or where, nevermind why or with what drawbacks.
Yes down-to-the-metal has it's places, No "places" is not a synonym for "everywhere". Considering his use of broad language:
Quote:And once you've built your own routines, they'll most likely be better than STL because _you_ designed it for _yourself_, and that leads to the most amount of code reusability in my book.
I cannot interpret his ramblings as anything less than blatently misleading. He does not say "better than the STL in the innermost loop of your render function". He does not say "better than the STL when you're shuffling elements around alot". He says plain, flat out better.
STL is ugly... because the C++ language is ugly. It is also damn useful. If you're going to ignore it because it's ugly, you might as well just move to a more readable language like C# or Python.
If I had to write, and rewrite, and rewrite, and... all of my container classes and basic algorithms over and over ad nauseum I'd go nuts. Plus, I already accept that there's no way I could code these classes as efficiently as the STL does.
Ugly syntax for an ugly language, but can't live without it.
If I had to write, and rewrite, and rewrite, and... all of my container classes and basic algorithms over and over ad nauseum I'd go nuts. Plus, I already accept that there's no way I could code these classes as efficiently as the STL does.
Ugly syntax for an ugly language, but can't live without it.
Quote:Original post by jpetrieQuote:
I don't see what is the problem to write a linked list?
Because yours will probably be less efficient, more buggy, and require other people who interact with your code to learn the ins and outs of your implementation, which is probably not as well documentated as std::list.Quote:
You can make all kind of special variations to the list which std won't give you.
Such as?
Well for a double linked list, putting a object in other (using <= operator).
Walking back and forth on the list with different behaviour when reaching the end or start of the list.
A special popper object which allows an object in the list to pop itself from the list without reference to the list.
And all sort of stuff.
Quote:Original post by The C modest god
Well for a double linked list, putting a object in other (using <= operator).
I do not understand.
Quote:Walking back and forth on the list with different behaviour when reaching the end or start of the list.
That's a function of your iteration look not a function of the list itself.
Quote:A special popper object which allows an object in the list to pop itself from the list without reference to the list.
Tell me how to do that while at the same time being able to find the length of the list in constant time.
Quote:Both this, and your rebuttal to my comment about std::string and strcat(), are valid situations where the STL's customization capabilities probably don't fit that specific situation ideally. My "such as" comment wasn't intended as "there is no such case" but rather to illicit a reply from C_Modest_God as to what situations he thought he needed that the STL couldn't provide (he may have had a specific one in mind that the STL could actually do; perhaps he just doesn't know about it?)
OK, fair enough :)
1)
Quote:The former interpretation isn't hard to accept at all, but everything I got (and the others that replied, it would seem) from bpoint's post indicated to me that he was advocating that it should never be used.
2)
Quote:He goes on in such a fashion never once stating any sort of qualifing remark about the STL having a place - only on and on about the shortcommings [sic] it has, and how unsafe C solutions are apparently superior - again, with no qualifing [sic] remarks about when or where, nevermind why or with what drawbacks.
He stated where he's coming from: "around seven years developing games on consoles where code must be designed for performance and a small memory footprint.". To me that defines the situation perfectly without having to append a "this may not apply in your situation" disclaimer to every sentence.
It seems that the people jumping on him missed that sentence and zoomed in on the rest; such is the hallmark of (this may sound negative but it's not meant in a derogatory manner) fanboys or zealots, quick to rebut any *perceived* criticism of their favorite tool.
Oh BTW: C++ compilers have definitely gotten better performance-wise; it may be worthwhile to re-examine which language features can be used. See Technical Report on C++ Performance.
Well, it looks like I only got slightly charred... I expected worse, actually. :)
Most of you seemed to have misinterpreted some of my post. Perhaps I didn't use the best choice of words in every sentence either.
First of all, I never said STL should be banished from existence or anything of that sort. If it works for you, great! I'm not here to change you from using something you like. But I do think that code that uses STL is rather difficult to read and debug, hence my original comment about it being horrid and ugly. I dunno, maybe I am stuck in my older ways? ;) I guess you could attribute part of the problem due to lack of a decent C++ compiler for game consoles. I think the first compiler that could even successfully compile templates was CodeWarrior on PS2 back in 2000? Certainly ProDG for PSX or N64 wasn't able to.
But when you design something (linked list, vectors, whatever) on your own, you learn the internals of how it works. This knowledge doesn't just confine itself to the code you've written, but rather to anything you write from then on. This is one of the reasons why I don't like STL and made the comment about programmers being lazy. I don't discourage the use of STL, but rather encourage people to learn how things are done on the insides. Don't just use a black box, but open it up and write your own implementation. The first attempt will almost always not be comparable, but you've gained knowledge and can then proceed to write a better one. A better one with more flexible design so it's not just for yourself, but for anyone who wants to use it. When I interview potential candidates for employment, I give plus points to someone who has shown the interest of looking on the inside of things.
Maybe I tend to have a more flexible schedule than other developers? But even then, my present company where I worked for started out with a zero code base. Avoiding STL and whipping up some of my own code didn't seem to take that long. Was it _better_ than STL? It depends on what your interpretation of better is. It suited us perfectly, and is still being used today. Are there programmers on my team who say we should move to STL? No, because what we have is fine.
I guess it all comes down to the OP's question:
No, you are not the only one. But we might be the only two. :)
Most of you seemed to have misinterpreted some of my post. Perhaps I didn't use the best choice of words in every sentence either.
First of all, I never said STL should be banished from existence or anything of that sort. If it works for you, great! I'm not here to change you from using something you like. But I do think that code that uses STL is rather difficult to read and debug, hence my original comment about it being horrid and ugly. I dunno, maybe I am stuck in my older ways? ;) I guess you could attribute part of the problem due to lack of a decent C++ compiler for game consoles. I think the first compiler that could even successfully compile templates was CodeWarrior on PS2 back in 2000? Certainly ProDG for PSX or N64 wasn't able to.
But when you design something (linked list, vectors, whatever) on your own, you learn the internals of how it works. This knowledge doesn't just confine itself to the code you've written, but rather to anything you write from then on. This is one of the reasons why I don't like STL and made the comment about programmers being lazy. I don't discourage the use of STL, but rather encourage people to learn how things are done on the insides. Don't just use a black box, but open it up and write your own implementation. The first attempt will almost always not be comparable, but you've gained knowledge and can then proceed to write a better one. A better one with more flexible design so it's not just for yourself, but for anyone who wants to use it. When I interview potential candidates for employment, I give plus points to someone who has shown the interest of looking on the inside of things.
Maybe I tend to have a more flexible schedule than other developers? But even then, my present company where I worked for started out with a zero code base. Avoiding STL and whipping up some of my own code didn't seem to take that long. Was it _better_ than STL? It depends on what your interpretation of better is. It suited us perfectly, and is still being used today. Are there programmers on my team who say we should move to STL? No, because what we have is fine.
I guess it all comes down to the OP's question:
Quote:em[sic] i alone out there or are there more who share this anger?
No, you are not the only one. But we might be the only two. :)
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
