STL is the bomb, I use it all the time.
I never liked MFC for obvious reasons. It's just too horrid.
I've never used ATL. I understand it's an STL-like effort. I consider it obsolete since the STL is here.
What I mean about heavyweight, is not necessarily big/bloated/slow, but also introducing extra dependencies in my application.
Normally, I like C++, STL (and the rest of the standard library), and a main function. I include the standard C/C++, and sometimes Unix, headers. I like to know about anything else I use that isn't my code.
Back when I was writing data mining servers, that was pretty much it. They would maybe use a third party library for neural networks and like functionality, but nothing more. The servers were clean. Sure, the GUI wrapped around them was Windows to the core and had a lot of dependencies, but the servers were clean programs with almost no dependencies.
The Windows headers are extra things. MFC is extra. ATL is extra. I like to know what my app is using. And I like it to be as little as possible. I don't use the Windows file functions, I use the C ones.
Right now, my game app is using C++ with STLport. It uses a tiny bit of Windows functionality (timers for profiling, maybe something else). It uses the generic text routines. It uses GapiDraw. I wrote my own parsers, matrix library, etc. I might someday add a fixed point library, either my own or a third party one I can just drop in via source code.
This has the side effect of keeping my app well contained for potential porting. I spent the first couple of years of my professional career porting complicated Windows enterprise applications (using OLE, COM, DLLs, you name it) from Windows to five flavours of Unix for a major software vendor. So reducing dependencies is something I tend to do as second nature now.
It would perhaps be nicer if derivation from ATL was a compile-time option. Those who want/need it can enable it, others such as myself can disable it. Just a suggestion.
