Quote:Original post by Noggs
I guessed when I was writing the comment about smart pointers on this forum that I was inviting some flaming [grin]. I concede that the use of shared_ptr is not so bad, however when it comes to stl that's a different matter, although it does depend on context. If working on a platform where memory is tight and per frame dynamic allocations are generally frowned upon, the use of stl can be crippling - particularly the std::string class - and very easy to abuse.

The other problem I have with it is that if you are just starting out the compile errors generated by using stl incorrectly can be pretty confusing.

Please understand I'm not advocating the approach of write everything yourself, by all means use shared_ptrs, vectors, strings. I'm just saying that it should not necessarily be the first port of call to solve a problem. Being forced to think carefully about exactly what you want to accomplish, what data is needed where and when, will result in faster and simpler algorithms.

I certainly agree that it is important to think about data lifetime; this is one of the key considerations when selecting a smart pointer class.

However, I strongly disagree with the conventional "wisdom" that using the standard library classes is bad for games - even for large-scale AAA console-bound titles. The thing that kills most people with the C++SL is a combination of poor algorithmic-level choices and poor understanding of memory allocators.

Fast allocators that are both C++SL-safe and performant for use on consoles are not that hard to write, especially since you can simply hook up existing well-understood fast allocation algorithms. Most good allocators out there provide C++SL allocator classes anyways.

There's really no excuse to avoid the C++SL these days. It takes a bit of low-level understanding to use it to its fullest potential, but that's even true on the PC.