Should I use Standard C++ Containers and Stuff for games and other real time activities?

Question

Hello,
I'm a C++ developer using VS 2012 and VS 2010 for developing AAA titles. I have read about not using STL and other stuff provided in the standard headers that come with VS. I read most of the stuff on the websites based on game programming and some
are really from the people well known in the industry. I have seen cases where they wont even use vector, list, map and others and not even use utility functions and algorithms. In such cases they write those containers and stuff themselves which has almost
the same interface and so much of debug and implementation time spent on such huge code.
I have two questions:
1: Isn't the C++ implementation that comes with VS optimized for the platform for better performance? Isn't it using some intrinsic functions that people on the client end doesn't know about and supplying their own implementation would indeed be
more slower in basic container operations such as insert, remove, find, swap, copy? Lets assume that we supply our own custom allocators for faster memory management to every container that we use. Also, they take care of fragmentation, alignment and stuff.
Why develop custom containers with almost same interface, why not spend that time on writing allocators and other stuff that might actually help?
2: There are times when we include a lot, a lot, of unnecessary stuff through the standard headers in a huge code base. Unnecessary, because we only needed a thing or two from such huge headers including other huge headers and so on. Now, I know templates
aren't instantiated unless used, same goes for the members functions inside them and blah blah. Since, these are precompiled headers, it is safe to assume that there is no compile time hit for that unnecessary stuff. My question is, is there any hidden effect
of such inclusions on code size (executable) that grows with the huge growth of the code base? In my opinion there shouldn't be, but I wanna know I'm not mistaken just in case. 

Answer 1

Hi
I can tell you a story about one of our projects. We had to implement a block management system for harddisks (like the parts of file systems that allocate, free blocks and do the bookkeeping stuff). Now, one guy was convinced, that we should use the STL,
because it's easy to use and very well optimized and things like that. An other one said, that he would implement it by hand. So we decided to do both for a little test. The result was, that the hand implemented thing was much easier to write and much faster...
and the one using STL saw, that some classes were so slow, that he couldn't believe it... he then tryed to build some classes by hand and exchange them (e.g. array classes and stuff like that) and it was way faster than the STL and he wrote them in minutes
(!)... since then nobody wanted to use STL again... we don't even try it. It ended that we wrote our own string and array classes and stuff like that... easy little things that we understand. Now it's easy to use and fast and still flexible, because we know
what it's doing...
... but, that's just a story about our development and of course, we're often programming very close to the hardware and also using assembler languages often... so, I don't know what this tells us... you have to decide :-)
Rudolf