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

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.

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.

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.

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.
[/quote]
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.