Why STL containers are preferred over MFC containers?

Question

Previously, I used to use MFC collection classes such CArray and CMap. After a while I switched to STL containers and have been using them for a while.

Answer 1

STL containers:

• Have performance guarantees
• Can be used in STL algorithms which also have performance guarantees
• Can be leveraged by third-party C++ libraries like Boost
• Are standard, and likely to outlive proprietary solutions
• Encourage generic programming of algorithms and data structures. If you write new algorithms and data structures that conform to STL you can leverage what STL already provides at no cost.

Answer 2

This is a case of whichever tools work for the job you want to do, and 'better' being a subjective term.

If you need to use your containers with other standards-compliant code, or if it is ever going to be code that is shared across platforms, STL containers are probably a better bet.

If you're certain that your code will remain in MFC-land, and MFC containers work for you, why not continue to use them?

STL containers aren't inherently better than MFC containers, however as they are part of the standard they are more useful in a wider range of contexts.

Answer 3

Ronald Laeremans, VC++ Product Unit Manager, even said to use STL in June 2006:

And frankly the team will give you the same answer. The MFC collection classes are only there for backwards compatibility. C++ has a standard for collection classes and that is the Standards C++ Library. There is no technical drawback for using any of the standard library in an MFC application.

We do not plan on making significant changes in this area.

Ronald Laeremans
Acting Product Unit Manager
Visual C++ Team

However, at one point where I was working on some code that ran during the installation phase of Windows, I was not permitted to use STL containers, but was told to use ATL containers instead (actually CString in particular, which I guess isn't really a container). The explanation was that the STL containers had dependecies on runtime bits that might not actually be available at the time the code had to execute, while those problems didn't exist for the ATL collections. This is a rather special scenario that shouldn't affect 99% of the code out there.

Answer 4

Next to the mentioned aspects: well-supported, standard available, optimized for performance, designed for use with the algorithms, I might add one more aspect: type-safety, and loads of compile-time checks. You can't even imagine drawing a double out of a std::set<int>.

Answer 5

In fact you can use STL algorithms on some of MFC containers as well. However, STL containers are preferred for another very practical reason: many third-party libraries (Boost, arabica, Crypto++, utf-cpp...) are designed to work with STL, but know nothing about MFC containers.

Answer 6

MFC containers derive from CObject and CObject has the assignment operator made private. I have found this very annoying in practice.

std::vector, unlinke CArray, guarantees that the memory block is contiguous, thus you can interop with C programming interfaces easily:

std::vector<char> buffer; 
char* c_buffer = &*buffer.begin();