Fog Creek Software
Discussion Board

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

Green Pajamas
Wednesday, May 19, 2004

If you want to have things like algorithm.h available to you, use STL containers.

Wednesday, May 19, 2004

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.

I suggest using STL unless you have to, because it's standardized and MFC isn't, but if you really like the MFC stuff then what the hell, you may as well use that...

Wednesday, May 19, 2004

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.

There's also some value in learning to think the STL way.

Michael Eisenberg
Wednesday, May 19, 2004

you might want to divide your application into
- presentation layer  (the gui stuff)
- logic layer              (logic stuff).

For the logic stuff it might make sence to use STL, since
you might not want to tie it in with MFC.
(today there is MFC, tomorrow there is something else)

This will help, if you decide to rewrite the application with a differnt user interface toolkit or on different platform.
(STL is portable - that's its strength).

Michael Moser
Thursday, May 20, 2004

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

In the case of CList, CArray etc. the framework is fighting *you* :)  The STL containers and algorithms are vastly more flexible, have guarantees about how they operate, and are less ugly (why on earth does MFC make you define the data type *and* the means of referring to it?!?  CList<CString, CString &> is just wrong).

Tim Serong
Thursday, May 20, 2004

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?

Mr Jack
Thursday, May 20, 2004

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.

Keith Wright
Thursday, May 20, 2004

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.

That said, in my MFC app, I did use STL for the few cases where I needed sorted lists and didn't feel like writing them myself.

David (
Thursday, May 20, 2004

*  Recent Topics

*  Fog Creek Home