I’ve been a long user of STLport, a portable implementation of the STL because the STL implementation in VC6 and VC7.0 has horrendous bugs, especially over DLL boundaries. Hence, I’ve never had a good opinion of Microsoft’s ability to implement the STL well (or rather, Dinkumware’s since MS just licensed it from them - but I like to point the blame at the person that took my money, personally ;)). VC7.1 has always had a better native STL implementation, but I refused to shell out the cash for an upgrade that in my opinion should have been a bugfix release to VC7.0, not a new product version.
Now I’ve upgraded to VC8, to my horror it came to my attention that every single OGRE demo was suddenly leaking memory at a rate of 60k/s. This, after we’ve spent so long eliminating these kinds of things. All previous versions of VC had completely stable memory usage on the exact same code. Where to start looking? OGRE isn’t exactly a small project.
In the end I got lucky. I noticed it was increasing at a very regular 1-second rate, and since most of OGRE runs at a much higher frequency than that, I guessed it had something to do with the frame rate stats, which are only updated every second. Sure enough, there it was - we use std::stringstream to convert numbers to text (rather than the nasty old sprintf), and guess what - the VC8 version is leaky as a damn seive. In fact, the whole of iostreams appears to leak badly in the most trivial usage. For shame!
Turns out this is a known bug. The workaround currently is to rebuild the faulty msvcp80.dll for yourself, which kind of makes a mockery of all the hoo-ha MS has been making about security validated versions of the runtime library, if you’re forced to deploy your own customised version of a core module to fix this. I suppose you can install it as a separate side-by-side assembly at least.
Still, it just reinforces my opinion - you can’t trust MS with the STL, they always seem to screw it up.