Jump to content

  • Log In with Google      Sign In   
  • Create Account

We're offering banner ads on our site from just $5!

1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.


Don't forget to read Tuesday's email newsletter for your chance to win a free copy of Construct 2!


STL, yay or nay?


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
17 replies to this topic

Poll: STL, yay or nay? (63 member(s) have cast votes)

Would you, or have you used STL in a game engine?

  1. Yes (56 votes [88.89%] - View)

    Percentage of vote: 88.89%

  2. No (7 votes [11.11%] - View)

    Percentage of vote: 11.11%

Vote Guests cannot vote

#1 Sepiantum   Members   -  Reputation: 102

Like
0Likes
Like

Posted 25 November 2011 - 11:36 PM

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.
Follow and support my game engine (still in very basic development)? Link

Sponsor:

#2 Promit   Moderators   -  Reputation: 7341

Like
6Likes
Like

Posted 25 November 2011 - 11:46 PM

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.

#3 D_Tr   Members   -  Reputation: 362

Like
0Likes
Like

Posted 26 November 2011 - 02:26 AM

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.

#4 frob   Moderators   -  Reputation: 22242

Like
2Likes
Like

Posted 26 November 2011 - 02:40 AM

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.

Check out my book, Game Development with Unity, aimed at beginners who want to build fun games fast.

Also check out my personal website at bryanwagstaff.com, where I write about assorted stuff.


#5 Ravyne   GDNet+   -  Reputation: 7778

Like
0Likes
Like

Posted 26 November 2011 - 02:43 AM

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.

#6 JTHSoftware   Members   -  Reputation: 102

Like
1Likes
Like

Posted 26 November 2011 - 02:53 AM

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.
Joshua Hoffmann
Developer, Land of Smiley Cubes
landofsmileycubes.com

#7 DaBono   Members   -  Reputation: 1006

Like
0Likes
Like

Posted 26 November 2011 - 03:09 AM

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).

#8 frob   Moderators   -  Reputation: 22242

Like
3Likes
Like

Posted 26 November 2011 - 03:22 AM

>> 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.

Check out my book, Game Development with Unity, aimed at beginners who want to build fun games fast.

Also check out my personal website at bryanwagstaff.com, where I write about assorted stuff.


#9 SiCrane   Moderators   -  Reputation: 9627

Like
3Likes
Like

Posted 26 November 2011 - 08:46 AM

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.

#10 Chris_F   Members   -  Reputation: 2438

Like
1Likes
Like

Posted 26 November 2011 - 10:21 AM

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. :blink:

Luckily this is changing.

#11 SiCrane   Moderators   -  Reputation: 9627

Like
0Likes
Like

Posted 26 November 2011 - 10:34 AM

C++ is probably the only language where people have been criticized for using the standard library. :blink:

It's happened in D too. Of course D 1.0 had this weird situation where the standard standard library was judged insufficient by some members of the community so an alternate, incompatible, standard library was developed. To this day I'm still unsure how exactly the Phobos/Tango split happened. Fortunately in D 2.0 this is no longer the case.

#12 Bearhugger   Members   -  Reputation: 566

Like
0Likes
Like

Posted 30 November 2011 - 03:16 PM

I also regret not having learned the STL sooner. There are things in the C++ standard or Boost libraries I don't use because I think they take the fun out of programming in C++ (such as the smart pointers: I prefer handling allocation and deletion myself) but collections classes are annoying to make and those of the STL are debugged, probably thread-safe, and peer-reviewed by people that know the language up to its smallest details, and I wouldn't have any fun writing them myself anyway.

My only complaint about it is purely cosmetic: its old all_in_lowerspace name styles clash uglily with the modern coding styles.

#13 swiftcoder   Senior Moderators   -  Reputation: 10238

Like
0Likes
Like

Posted 30 November 2011 - 03:57 PM

My only complaint about it is purely cosmetic: its old all_in_lowerspace name styles clash uglily with the modern coding styles.

Amusingly enough, CamelCase dates back to the 1970's, while underscores are quite popular with 'modern' languages (Python, C++, etc.).

Tristam MacDonald - Software Engineer @Amazon - [swiftcoding]


#14 NightCreature83   Crossbones+   -  Reputation: 2933

Like
0Likes
Like

Posted 30 November 2011 - 05:32 PM

I also regret not having learned the STL sooner. There are things in the C++ standard or Boost libraries I don't use because I think they take the fun out of programming in C++ (such as the smart pointers: I prefer handling allocation and deletion myself) but collections classes are annoying to make and those of the STL are debugged, probably thread-safe, and peer-reviewed by people that know the language up to its smallest details, and I wouldn't have any fun writing them myself anyway.

My only complaint about it is purely cosmetic: its old all_in_lowerspace name styles clash uglily with the modern coding styles.


The _Capital character stuff STL uses is due to the fact that that particular format is reserved for global scoped identifiers and that is what you want your standard library to use and not much else. And seeing that STL is often implemented by the compiler coders they are implemented as first class identifiers and hence use the reserved formats.

See this link for more info.

On the current gen consoles there are still differences between STL versions and so it is better to use your own STL versions, whether they are wrappers over the platform STL or your own implementations. This allows you to provide one interface to all the code above it which makes writing code for multiple platforms far easier.

Having said that you best learn how to use STL as even the custom implementations often just follow the normal STL interface.


Worked on titles: CMR:DiRT2, DiRT 3, DiRT: Showdown, GRID 2, Mad Max

#15 mhagain   Crossbones+   -  Reputation: 8140

Like
0Likes
Like

Posted 30 November 2011 - 07:16 PM

I have, BUT.

I'd strongly advise against using STL for runtime dynamic allocations (the exception is if you can pre-size your containers at load time). Unless you understand that what's going on behind the scenes is much the same as good-old malloc/free/realloc, then you're liable to hurt performance. Where I've found it really handy is for lists of resources (such as textures - I keep my LPDIRECT3DTEXTURE9s in an std::vector) where you don't really want to specify an upper limit but you have a potentially unknown quantity and you're not going to be needing to grow or shrink the list on any kind of a regular basis.

Having said that, STL will make your job a LOT easier when you're learning things. It nicely removed much of the burden of managing container types from your own code, allowing you to concentrate more on what your program does rather than on how it does it. Later on I would recommend that you bone up on what's happening behind the scenes, because it will enhance your understanding and enable you to make some better judgement calls on how and when to do certain things.

It appears that the gentleman thought C++ was extremely difficult and he was overjoyed that the machine was absorbing it; he understood that good C++ is difficult but the best C++ is well-nigh unintelligible.


#16 swiftcoder   Senior Moderators   -  Reputation: 10238

Like
1Likes
Like

Posted 30 November 2011 - 08:31 PM

I'd strongly advise against using STL for runtime dynamic allocations (the exception is if you can pre-size your containers at load time). Unless you understand that what's going on behind the scenes is much the same as good-old malloc/free/realloc, then you're liable to hurt performance.

Except that there is no need to replace the STL containers to fix this. It just requires the use of a replacement allocator, such as the one's supplied by the Boost pool allocators.

Tristam MacDonald - Software Engineer @Amazon - [swiftcoding]


#17 rip-off   Moderators   -  Reputation: 8517

Like
1Likes
Like

Posted 01 December 2011 - 03:55 AM

There are things in the C++ standard or Boost libraries I don't use because I think they take the fun out of programming in C++ (such as the smart pointers: I prefer handling allocation and deletion myself) ...

We obviously have different standards of "fun" =]

... but collections classes are annoying to make and those of the STL are debugged, probably thread-safe, and peer-reviewed by people that know the language up to its smallest details, and I wouldn't have any fun writing them myself anyway.

The Standard C++ Library containers are not thread safe. This consideration is not part of their specification.

They probably should not be thread safe either, due to the overhead this would require when they are not shared, and due to the fact that thread safety at the level of an individual class is often too low level, instead you need to have thread safety around a logical transaction.

#18 SiCrane   Moderators   -  Reputation: 9627

Like
0Likes
Like

Posted 01 December 2011 - 09:07 AM

The Standard C++ Library containers are not thread safe. This consideration is not part of their specification.

Thread safety isn't a binary yes/no. There are degrees of thread safety. You have to consult your compiler/standard library documentation to be sure, but most implementations offer the most basic of guarantees: as long as the allocator can be used safely across threads simultaneously safely, then two instances of containers can be modified safely in their own threads. Yes, this seems like a well-duh degree of safety, but it's possible to create a container implementation that doesn't give you this guarantee, for example, by using global state.




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS