STL why's and why not's in game programming

Started by
28 comments, last by _the_phantom_ 19 years, 4 months ago
Hello. I'm pretty new in the "professional" game developer scene and found out that old demo-programmers seems to avoid STL and all the sweet libs that boost presents. The only reason they're writing their own string-, vector and mathclasses is that "stl is generating to big of a overhead" and "i want total control of my application" I found that really irritating: no matter how good your string-class is, it wont be as heavily tested as std::string and your matlib will probably never be as fast and optimized as D3DX******** So... are you an old demo-programmer or a cool dude? I'm using stl and boost whereever I can - AND if it is approperiate
Ethereal
Advertisement
Quote:Original post by Metus
The only reason they're writing their own string-, vector and mathclasses is that "stl is generating to big of a overhead" and "i want total control of my application"


I would say the real reason is lack of knowledge & old compilers give you misconceptions [wink]

Quote:Original post by Metus
So... are you an old demo-programmer or a cool dude?


Nothing about being cool, just not being ignorant & arrogant [grin] and wasting your's and compiler implementor's time & money.
Maybe 5-10 years ago or so when computers were slow enough to warrent such control/optimizations, then ya, STL would seem like a huge overhead. Today however, there is no reason to go recreate a String class or a dynamic array (vector) and especially Sets, Maps and Hashmaps (red-black trees....*shudder*).

We are in the programming age of using highly optimized libraries created so we can spend more time on our application itself. The tools are there, the overhead is negligable, use them.
I agree that there is no real reason to reinvent the basic parts of the STL, like the string and vector classes... But, some things are badly implemented in STL, like the auto_ptr. As for math libraries, its very possible to come up with better optimizations than the d3dx math. Also, the d3d math classes are not portable... Plus, its a little annoying that a 3D API tries to impose you its own 3d math stuff.

My 3D engine supports both OpenGL and D3D at the low level. We have an abstract DLL interface low level enough to render vertex buffers in both... And uh, its sort of, part of the point of this system not to include the neither the d3d or the OpenGL libraries in the engine. There isn't that much math stuff to code, and for the flexibility it can bring, its worth it to implement it yourself.

Looking for a serious game project?
www.xgameproject.com
Everyone should write their own string, hashmap, and math vector classes for learning purposes, but then use the standard libraries in real code.
Speaking of performance and STL, everyone should check this out.

Go to:

http://www.gdconf.com/archives/2004/index.htm

Check out the powerpoint: Common C++ Performance Mistakes in Games

Many of the performance problems are due to mis-use of STL. With a better understanding of what some of the functions do, and properly using them you can eliminate alot of the performance overhead. Some of the examples in the article make me think "wtf were they thinking", but I learned some new stuff from it.
Quote:Original post by Anonymous Poster
Everyone should write their own string, hashmap, and math vector classes for learning purposes, but then use the standard libraries in real code.


Exactly. As a beginner myself (3 months so far), I don't want to blindly use the STL without at least understanding how the classes work. For me, the best way to understand how they work is to come up with my own implementation. I've done a string class, math vector class, and a pseudo-hash table. I'm currently learning about exception handling and the STL for use in my next project [smile].
Quote:Original post by ontheheap
For me, the best way to understand how they work is to come up with my own implementation.


By all means if you haven't taken or currently taking a course on data structures & algorithms then it is worth doing your imps just to learn.

Actually i think if you open up your compiler's implementation of STL you'll learn even more, aswell as learning the structure you'll learn common techniques & idioms to overcome language flaws, i really recommend everyone has glance at them at least once, you'll see things such as:

Empty Base optimization (EBO)
resource acquisition is initialization (RAII)
type traits & compile-time dispatch on types (e.g if its a POD type use memcpy instead, this is at compile time not run-time).

being employed.
Using STL and boost is likely to make your game _much faster_!

Reasoning:

The three man-months you avoid mucking with your own container implementations etc. at the _start_ of the project can instead be spent when the game actually works. Imagine having three man-months to profile and optimize the **** out of the game where performance _actually matters_.

I know where I'd rather spend months.

Most optimizations before the program is completed are random speculations and make the code _worse_ and harder to optimize.

Make you game _work_. Use all the ready-to-use stuff you can find, even including stuff you know you can't use in shipping game. Make it work!

_Then_ optimize it where it matters. Then replace that copyrighted temp stuff with your own code.

How many percent of hobby game projects are completed? Not many I would guess. Everyone is busy writing string classes until they get bored with the project :-)


/Marcus
Quote:Original post by snk_kid
Quote:Original post by ontheheap
For me, the best way to understand how they work is to come up with my own implementation.


By all means if you haven't taken or currently taking a course on data structures & algorithms then it is worth doing your imps just to learn.

Actually i think if you open up your compiler's implementation of STL you'll learn even more, aswell as learning the structure you'll learn common techniques & idioms to overcome language flaws, i really recommend everyone has glance at them at least once, you'll see things such as:

Empty Base optimization (EBO)
resource acquisition is initialization (RAII)
type traits & compile-time dispatch on types (e.g if its a POD type use memcpy instead, this is at compile time not run-time).

being employed.


It's part of my major, but I haven't taken it yet. I definitely plan on checking out the STL implementation for my compiler. Plus since I've written the classes myself, I can see how they went about solving the same problem and learn more in the process.

This topic is closed to new replies.

Advertisement