The main problem with V-man's stance is that he is the only one in the world that understands his custom containers or whatever. This is generally true for people that advocate avoiding the STL.
The most important thing about the STL after you get through the whole perf argument is that it's the StandardTL. Anybody who claims to know C++ should be able to sit down and know how to use these things with no special training or ramp up time.
I can sympathize, I don't like a lot of the conventions used in the STL, particularly the naming. But having other people be able to understand my code, and not having to remember how to use my own custom stuff after not having looked at it for six months or whatever, is way more important than petty details.
The Myth About STL
Which is why it can be awfully nice to have a container library that looks like the STL, but has less stupid rules with regards to allocators etc. That's what EASTL accomplishes, really.
What stupid rules does STL have with regards to allocators? Do you mean that allocators have to be stateless?
Quote:Original post by cache_hitEASTL paper, section on allocators
What stupid rules does STL have with regards to allocators? Do you mean that allocators have to be stateless?
Just a side note, since EASTL isn't publicly available, one must make do with what is. Thankfully, there are some parts of boost that might come in handy when the standard library doesn't provide the performance you desire:
boost::array: fixed size array with an iterator interface.
boost::intrusive: Intrusive containers, and lots of them (lists, sets, splay trees, hashtable, etc.)
Unrelated to boost, there is also Simon Brown's awesome pool allocator.
Of course, if all else fails and you really do need to write a highly optimized generic container, and you have the cojones, there's always boost::mpl.
boost::array: fixed size array with an iterator interface.
boost::intrusive: Intrusive containers, and lots of them (lists, sets, splay trees, hashtable, etc.)
Unrelated to boost, there is also Simon Brown's awesome pool allocator.
Of course, if all else fails and you really do need to write a highly optimized generic container, and you have the cojones, there's always boost::mpl.
Quote:Original post by V-man
Lastly, rolling your own code.... I have done that a long long time ago. Once you write code, it never expires.
Standards change or get updated so I wouldn't say thats really true. Unless you personally keep on top of things like that it would be very easy to let subtle bugs work their way in. Much easier to let the people who were involved with the changes make those kinds of updates.
Figuring out how the complex things work is what makes you a better programmer.
STL will be faster with C++0x
If you know how STL works then it can be very fast. But if you don't know (don't know how objects behave) it can be very slow.
The main problem is objects are copied
STL have a high knowledge threshold
If you know how STL works then it can be very fast. But if you don't know (don't know how objects behave) it can be very slow.
The main problem is objects are copied
STL have a high knowledge threshold
Whether STL is fast or not is not really the question. The question is, do you have code that already does the job? If you are new to programming, then you need ready made solutions like STL and the whole slew of others that exist on sourceforge.
It is the same for Direct3D and OpenGL. These are barebone. A newbie needs to load textures, models, etc. That's why D3DX exists and GLU(and a bunch of other free libs).
Someone who is not a newbie, doesn't care for certain libraries like D3DX and GLU.
STL falls in the category of "do not use" for me. It would be inelegant if I mix my code that does the same thing and STL in the same project.
I'm not saying I don't use external libraries at all.
And if you are a newbie, I can understand that you don't know what to do and you will listen to others for guidance and end up with STL in your project :)
You guys seem to have this idea that YOU MUST USE STL OR ELSE YOU ARE AN IDIOT.
It is the same for Direct3D and OpenGL. These are barebone. A newbie needs to load textures, models, etc. That's why D3DX exists and GLU(and a bunch of other free libs).
Someone who is not a newbie, doesn't care for certain libraries like D3DX and GLU.
STL falls in the category of "do not use" for me. It would be inelegant if I mix my code that does the same thing and STL in the same project.
I'm not saying I don't use external libraries at all.
And if you are a newbie, I can understand that you don't know what to do and you will listen to others for guidance and end up with STL in your project :)
You guys seem to have this idea that YOU MUST USE STL OR ELSE YOU ARE AN IDIOT.
Quote:Original post by V-man
You guys seem to have this idea that YOU MUST USE STL OR ELSE YOU ARE AN IDIOT.
No, but you must have a good reason for not using it, or else perhaps you are. "I'm not good enough, I'm too much of a beginner" is not a good reason. If you're not good enough to use STL, why should anyone have any confidence that you're good enough to program a game? Everyone is a beginner at some point, but without being a self starter and having a desire to learn and grow, you won't make it very far. Yes C++ and templates are hard. So is game programming.
Quote:Original post by V-man
It is the same for Direct3D and OpenGL. These are barebone. A newbie needs to load textures, models, etc. That's why D3DX exists and GLU(and a bunch of other free libs).
Are you implying that pros don't use D3DX, GLU, and other free libs that make things easier?
A pro is someone who gets the job done efficiently and to the point. Not someone able of writing tons and tons of code that reinvents the wheel.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
