Why STL containers are preferred over MFC containe

问题:

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. Although I find STL much better, I am unable to pin point the exact reasons for it. Some of the reasoning such as :

1. It requires MFC: does not hold because other parts of my program uses MFC
2. It is platform dependent: does not hold because I run my application only on windows.(No need for portability)
3. It is defined in the C++ standard: OK, but MFC containers still work

The only reason I could come up is that I can use algorithms on the containers. Is there any other reason that I am missing here - what makes STL containers better than MFC containers?

回答1:

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.

回答2:

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.

回答3:

• Compatibility with other libraries (such as boost) in syntax, interoperability, and paradigm. It's a non-trivial benefit.
• Using STL will develop a skillset that is more likely to be useful in other contexts. MFC isn't so widely used any more; STL is.
• Using STL will develop a mindset that you may (or may not) find useful in code you write yourself.

Using something other than STL isn't inherently wrong though.

回答4:

• STL has more collection types than MFC
• Visual Studio (2008+) debugger visualizes STL much better than MFC. (AUTOEXP.DAT magic can fix that - but it is a pain! Nothing like debugging your debugger when you screw it up...)

One good thing with MFC is that there is still a large corpus of MFC code out there. Other answers talk about third-party compatibility. Don't forget third party MFC-based stuff.

回答5:

I always prefer using more standard/compatible libraries where I can since I may have future projects that I can reuse a portion of the code on. I have no idea what libraries future projects will use, but I have a better chance of making my code reusable if I use standard/compatible stuff.

Also, the more I use a library, I get more comfortable and quicker with it. If I am going to invest the time to learn a library, I want to make sure it's going to stay around and is not tied in with a specific platform or framework.

Of course, I say all of this assuming that my choices are rather similar when it comes to performance, features and ease of use. For instance, if the MFC classes are a significant enough improvement in these areas, I would use them instead.

回答6:

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.

回答7:

It is now assumed that C++ developers are at least passingly familiar with the STL. Not so for MFC containers. So if you're adding a new developer to your team, you will have an easier time finding one who know STL than the MFC containers, and thus will be able to contribute immediately.

回答8:

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();

回答9:

I think it boils down to a simple question: Who do you trust more? If you trust Microsoft, then continue to use the MFC variants. If you trust the industry, then use STL.

I vote for STL because the code that runs on Windows today might need to be ported to another platform tomorrow. :)

回答10:

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.

回答11:

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

回答12:

Because a library that uses iterators to combine sequences of any kind with algorithms so that A) all sensible permutations are possible and B) it's universally extensible, is (when you think about your concept of a container library as it was 15 years ago) such a mind-blowingly marvelous idea, that it has pretty much blown out of the water everything else within less than a decade?

Seriously, the STL has its flaws (why not ranges instead of iterators? and that erase-remove idiom is not exactly pretty), but it's based on a brilliant idea and there's very good reasons we don't need to learn a new container/algorithms library every time we start at a new job.

回答13:

I wouldn't totally dismiss the portability argument. Just because you use MFC today doesn't mean that you always will. And even if you mostly write for MFC, some of your code could be re-used in other applications if it were more generic and standards-based.

I think the other reason to consider STL is that its design and evolution has benefited from libraries that have come before, include MFC and ATL. So many of the solutions are cleaner, more re-usable, and less error prone. (Though I wish they had a better naming convention.)