STL, yay or nay?
Author
The use of C++'s STL has been widely disputed over time, and I'm confused as to if one should use it in a game engine or not. Post your ideas on its use and I will take them into consideration in my journey into the creation of a game engine.
My rule of thumb is that if you have to ask, you are nowhere near the experience or skill to justify not using it. And many, many commercial AAA console games have shipped with it.
One thing is for sure: your first (and second and third) game engine won't be bottlenecked by the STL in any way. Plus, you also get to save time in order to devote more time into the actual game engine code.
Rules like that need context.
Go WAY back to before C++ was standardized (almost 14 years ago) and it made tons of sense. The rule was simple: Don't use it because it didn't really exist as a standard. It was an external library that was unproven on the tiny game systems.
Later after the standard it was a bit more complex. Machines were bigger and faster. Some systems were great, but other compilers had bad support. Optimizations that are common today were not used back then. Templates were bloated because compilers would blindly duplicate code. Template expansions could be so large they broke debuggers and tools. Support on smaller compilers ranged from poor to non-existent. Not using it in console games was good advice back in 1999 to 2001 or so. On a few oddball systems the advice may still be valid.
Today those are not true. All major compilers and tools have excellent support. More programmers understand the libraries and are able to use them properly.
You always need to understand the context of rules like this. Fancy bit tricks that made sense in a world of un-pipelined CPUs with no cache are huge performance killers on heavily pipelined out-of-order processing cores. Advice that made sense for single processors doing time-sliced threading can be horrible for multi core machines we use today. Advice from years past may not apply today. You must understand the context.
Go WAY back to before C++ was standardized (almost 14 years ago) and it made tons of sense. The rule was simple: Don't use it because it didn't really exist as a standard. It was an external library that was unproven on the tiny game systems.
Later after the standard it was a bit more complex. Machines were bigger and faster. Some systems were great, but other compilers had bad support. Optimizations that are common today were not used back then. Templates were bloated because compilers would blindly duplicate code. Template expansions could be so large they broke debuggers and tools. Support on smaller compilers ranged from poor to non-existent. Not using it in console games was good advice back in 1999 to 2001 or so. On a few oddball systems the advice may still be valid.
Today those are not true. All major compilers and tools have excellent support. More programmers understand the libraries and are able to use them properly.
You always need to understand the context of rules like this. Fancy bit tricks that made sense in a world of un-pipelined CPUs with no cache are huge performance killers on heavily pipelined out-of-order processing cores. Advice that made sense for single processors doing time-sliced threading can be horrible for multi core machines we use today. Advice from years past may not apply today. You must understand the context.
Yes absolutely. Learn to use it and it will treat you well, master it and it will treat you even better. Only consider rolling your own when you're certain you've used the STL containers as efficiently as they allow themselves to be (e.g. If allocation is a bottleneck, use custom allocators).
Algorithmically, the STL is pretty sound, however you may find situations where a purpose-built approach could exploit assumptions, or that the STL doesn't provide a good data structure for. Assuming boost doesn't have a good solution either, then consider implementing your own.
Algorithmically, the STL is pretty sound, however you may find situations where a purpose-built approach could exploit assumptions, or that the STL doesn't provide a good data structure for. Assuming boost doesn't have a good solution either, then consider implementing your own.
EDIT: Just noticed Ravyne's post... he said what I was trying to say better than I did. 
About seven years ago (2004), I used STL in one of my projects. Back then, I was still using Visual C++ 6.0.
Then I decided to look into porting that project to Linux. I figured a good "stepping stone" would be to compile it using a Windows version of GCC. I can't remember if it was MingW or Cygwin.
GCC gave all sorts of compiler errors, and they were caused by differences between how STL is implemented in different compilers.
So I decided to replace all usage of STL classes with my own custom-made classes, where I could guarantee that if it compiles in one compiler, then it'll compile in others. I figured I wouldn't have to worry about STL having "breaking changes" in "future" compilers such as Visual C++ 2005 and updates to GCC.
I found other problems with STL too. So I've been using my own custom classes since then. Because of that, I don't really know if all these problems with STL have been solved in the newest compilers like Visual C++ 2010 and the newest versions of GCC.
Now I regret not using STL recently as I've been applying for jobs and I wind up taking tests which ask STL questions. And that particular job description didn't even mention STL. I guess some people feel that if C++ is mentioned in the job description, then knowledge of STL is implied.
So if I were in your shoes, I would use STL. However, be prepared for the possibility that you may run into weird problems with STL later on. I would make your code flexible enough that you could substitute custom classes in place of STL classes later on if the need arises.
About seven years ago (2004), I used STL in one of my projects. Back then, I was still using Visual C++ 6.0.
Then I decided to look into porting that project to Linux. I figured a good "stepping stone" would be to compile it using a Windows version of GCC. I can't remember if it was MingW or Cygwin.
GCC gave all sorts of compiler errors, and they were caused by differences between how STL is implemented in different compilers.
So I decided to replace all usage of STL classes with my own custom-made classes, where I could guarantee that if it compiles in one compiler, then it'll compile in others. I figured I wouldn't have to worry about STL having "breaking changes" in "future" compilers such as Visual C++ 2005 and updates to GCC.
I found other problems with STL too. So I've been using my own custom classes since then. Because of that, I don't really know if all these problems with STL have been solved in the newest compilers like Visual C++ 2010 and the newest versions of GCC.
Now I regret not using STL recently as I've been applying for jobs and I wind up taking tests which ask STL questions. And that particular job description didn't even mention STL. I guess some people feel that if C++ is mentioned in the job description, then knowledge of STL is implied.
So if I were in your shoes, I would use STL. However, be prepared for the possibility that you may run into weird problems with STL later on. I would make your code flexible enough that you could substitute custom classes in place of STL classes later on if the need arises.
When you're a hobbyist, simply use STL. It will make you more productive (you're using your time to write your game, not linked-list implementations). It's a great general purpose library.
And that's exactly why it's sometimes despised. Games are quite a niche, and especially memory management can be quite tricky. That's what gave rise to things like EASTL (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2271.html).
And that's exactly why it's sometimes despised. Games are quite a niche, and especially memory management can be quite tricky. That's what gave rise to things like EASTL (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2271.html).
>> About seven years ago (2004), I used STL in one of my projects. Back then, I was still using Visual C++ 6.0.
You were already a few years out of date. You could have updated to the (then free) Visual C++ 2003 express edition compiler or 2002 compiler. The VC6 compiler was rushed because of the C++ standard, they wanted it out the door before the standard was ratified in 1998.
>>Now I regret not using STL recently as I've been applying for jobs and I wind up taking tests which ask STL questions. And that particular job description didn't even mention STL. I guess some people feel that if C++ is mentioned in the job description, then knowledge of STL is implied..
I agree with those employers. The standard libraries compose about 2/3 of the language standard. Saying you know c++ but don't understand the standard library is akin to saying you don't have a firm grasp on how classes or inheratance works.
>> So if I were in your shoes, I would use STL. However, be prepared for the possibility that you may run into weird problems with STL later on. I would make your code flexible enough that you could substitute custom classes in place of STL classes later on if the need arises.
There should be no major issues using the standard libraries. They are standard, well written, and debugged. If you have a problem it will be due to your own lack of understanding and bugs. I agree that you should make your code flexible, but saying "in case the need arises" would be like suggesting a need may arise that memcpy or printf or cout or other core language functionality may somehow break and need to be replaced. You may someday find your own requirements changing, but those are so basic to the language that what you describe is an unfounded fear.
The standard library has grown, but the existing interfaces and specifications are basically unchanged since the original 1998 standard. There were a very small number of bugs within the standard itself, but those were quickly corrected. These were generally not breaking changes unless you had written cod that relied on the bug, which was a very rare occurance.
You were already a few years out of date. You could have updated to the (then free) Visual C++ 2003 express edition compiler or 2002 compiler. The VC6 compiler was rushed because of the C++ standard, they wanted it out the door before the standard was ratified in 1998.
>>Now I regret not using STL recently as I've been applying for jobs and I wind up taking tests which ask STL questions. And that particular job description didn't even mention STL. I guess some people feel that if C++ is mentioned in the job description, then knowledge of STL is implied..
I agree with those employers. The standard libraries compose about 2/3 of the language standard. Saying you know c++ but don't understand the standard library is akin to saying you don't have a firm grasp on how classes or inheratance works.
>> So if I were in your shoes, I would use STL. However, be prepared for the possibility that you may run into weird problems with STL later on. I would make your code flexible enough that you could substitute custom classes in place of STL classes later on if the need arises.
There should be no major issues using the standard libraries. They are standard, well written, and debugged. If you have a problem it will be due to your own lack of understanding and bugs. I agree that you should make your code flexible, but saying "in case the need arises" would be like suggesting a need may arise that memcpy or printf or cout or other core language functionality may somehow break and need to be replaced. You may someday find your own requirements changing, but those are so basic to the language that what you describe is an unfounded fear.
The standard library has grown, but the existing interfaces and specifications are basically unchanged since the original 1998 standard. There were a very small number of bugs within the standard itself, but those were quickly corrected. These were generally not breaking changes unless you had written cod that relied on the bug, which was a very rare occurance.
There should be no major issues using the standard libraries.
Actually, there still remains one major issue. On platforms with poor exception handling, including many embedded platforms and some consoles, it becomes a legitimate option to disable exception handling. Since most of the standard library uses exception handling to signal errors, in that case, avoiding the relevant portions of the standard library in favor of in house or third party libraries makes sense. Hopefully in a few years this will no longer be a relevant caveat.
A decade or more ago, anti-STL mentality may have made sense, but not in 2011.
C++ is probably the only language where people have been criticized for using the standard library.
Luckily this is changing.
C++ is probably the only language where people have been criticized for using the standard library.
Luckily this is changing.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
