Some posters mentioned here, that STL could be very effective, when used properly. But main problem, IMHO, is in this proper usage, you should spend weeks (or even months) of time to begin understand right usage of stl, when to use is_empty or when use (count == 0) for example. Why there are so much books written about proper use of STL?
I think, that STL is universal container, when in games we don't need this univesality, so it is neccessary to write your own container. But you should know STL, because there are many good architectural and algorithmical concepts applied.
PS: Assembler, generated from code with stl usually uglier than one generated from your own (But it's also depends on 'how good you are at programming' :) ).

Quote:Original post by EasilyConfused
I feel that could mislead into thinking that the STL's generality somehow compromises its efficiency. It does not in all but the most extreme and contrived cases. That is one of the best things about it.

Is not game development extreme and contrived case? :)
You must get from processor as much, as possible, and every excess tick on operation, performed in main loop gives you fps loss.

Quote:
Assembly can be as ugly as it wants as long as we don't have to look at it.

Checking assembly is a neccessary case because sometimes compiler goes crazy on absolutely simple cases. For example some days ago we found that usage of unsigned int and float created VERY bad code - compiler generated tons of absolutely unneeded instructions (This is only example of need to check assembly).

Quote:
Find me an example of an STL container or algorthim being outperformed by a user-created equivalent in a way that ACTUALLY IMPACTS UPON AN APPLICATION IN A MEANINGFUL WAY and I'll shut up.

I think this algorithm could be sorting one :)

Well, I don't want to say, that own-made bicycle is a better one, however my point is, that usually I don't need all that complexity, that brings STL. I must think about memory allocation strategy, when my task is simple iteration over list members for example.

Quote:Original post by const
I think, that STL is universal container, when in games we don't need this univesality, so it is neccessary to write your own container.

Whoa whoa whoa, where'd we jump from "don't need feature X" to "we need to rewrite this"?

Yes, there will be some 10, 1, or 0.1% of cases where, gosh darn it, your container usage is a bottleneck and no STL container can quite do the job you need done, at the speed you need it done. By using the STL in the 90, 99, or 99.9% remaining cases, you can focus on spending your time optimizing where it counts, instead of repeatedly reinventing the wheel every few seconds for no good reason. Given how good optimizers are these days, it's going to be damn hard to beat the compiler in a lot of circumstances, especially when it boils down to repeating exactly what the STL version would do.

While some parts of game programming are extreme, contived cases, there are a lot of parts where it is not. If you spend 10 hours optimizing a game, you're going to get better results by focusing on where it matters rather than spreading it paper thin everywhere. This is common sense!!

Quote:Original post by const
Well, I don't want to say, that own-made bicycle is a better one, however my point is, that usually I don't need all that complexity, that brings STL. I must think about memory allocation strategy, when my task is simple iteration over list members for example.

for ( container_type::iterator i = container.begin() ; i != container.end() ; ++i ) {    //use i}

Could you please point out where I worried about memory allocation strategy? I can't find it.

Just use it.

Get the code done, make it work, profile, AND THEN optimize. Things change as your code base grows, requirements change, designs change. Why waste time rolling your own tightly optimized linked-list if you might just toss it out in the end because a straight array turned out to be faster? What you spend time optimizing may end up inconsequential due to a bottleneck.

When you do optimize, remember to optimize the algorithm first. Use a list if you need fast inserts/deletes at any location. Use a vector if you need fast traversals. Write a custom allocator if memory allocation is an issue. If all else fails, then roll your own.


What is it with C++? No one using C# seems to question using the .Net Standard Library... no wonder people find themselves more productive... they aren't reinventing the wheel all the time.

Admit it, it's fun to rewrite the obvious to fool yourself into thinking you are doing something productive.

Quote:Original post by EasilyConfused
@const (cool nickname, BTW). I feel that could mislead into thinking that the STL's generality somehow compromises its efficiency. It does not in all but the most extreme and contrived cases. That is one of the best things about it.

Assembly can be as ugly as it wants as long as we don't have to look at it. Find me an example of an STL container or algorthim being outperformed by a user-created equivalent in a way that ACTUALLY IMPACTS UPON AN APPLICATION IN A MEANINGFUL WAY and I'll shut up.

A good example is where many allocations/deallocations happen in a short time frame and the system's malloc implementation is not the best. Of course there is a way to work around this by making an object cache out of stl templates and using that, but it requires as much effort as making your own array based object pool. So the best example is the memory and speed contrained application where allocating objects from the heap would be too slow. Also a custom container can wrap the control info and the actual data into one large malloc()-ed or mmap()-ed block.

I don't really buy the argument that "smarter people have worked on it, therefore you don't need to write one".

One of the very basic parts of a language is it's memory manager. new and malloc SUCK. They fragment memory and are unusable on a platform with a fixed memory footprint.

Why am I to believe that this nebulous standard template library (which implementations change from compiler to compiler) would be better suited than something I can write.

I write for consoles. Certain current generation consoles have small L1 caches, and no L2 cache. Cache coherency is CRITICAL. How can I be sure that the STL will respect that and write code with good data and code locality in mind?

I can't, and most of the time, it doesn't.

STL is easier, but doesn't nessecarily mean it's BETTER.

I know this is a bit of a religeous topic, and I certainly can see how STL is very useful. Especially for PCs, in which software is written mostly to libraries and an operating system, and doesn't have such an intimate correlation with the hardware. But there is a huge games market in which it is critical that the developers have full control over the libraries that they use.

I just hate to see people act as if someone would be crazy not to use STL. STL has it's place, but is certainly not the be-all end-all