Using STL in MFC Applications
Should I use std::string and STL containers or stick to CString (which I still can't avoid) and MFC Collections? I won't be porting it to any other platform or compiler. Just wondering how much does it add to the total file size? And what real benefit I'll get from using STL (from within MFC applications)?
If you want to have things like algorithm.h available to you, use STL containers.
No real benefit either way. Similar facilities are provided by both, but I think the STL is better designed. The algorithms and so on are pretty handy, provided you don't try and be too clever with bind1st and bind2nd.
STL is also not platform-specific, which may mean there's a larger body of developers working with it, and therefore more code you can lift from other sources.
you might want to divide your application into
"Don't fight the framework". CString is your friend, because it's used in so many MFC calls. If you use std::string instead, you'll have to keep creating CStrings any time you want to deal with MFC, which is unnecessarily inefficient.
CString is one of the best classes in MFC, it is the only one that doesn't continually pour grief on you. One thing I don't understand though is why they chose to have CString, BSTR and bstr_t?
CString has a couple annoyances. One is in debugging: If you try to change the value of the string in the debugger, you may also be changing the value of any other string that is equal, because of CStrings copy-on-write mechanism. And doesn't it also have threading issues? But I'm so much more used to CString than std::strings that I haven't bothered even trying out std::string instead.
Tim Serong is dead on. If you don't need to be multiplatform, go with what your platform provides. If you are using MFC, you are going to want CStrings. There's no need to clutter your code with too many different classes that do basically the same thing.
Fog Creek Home