为什么 STL 容器优于 MFC 容器？
以前，我曾经使用MFC集合类，例如CArray和CMap。一段时间后，我切换到 STL 容器并已经使用它们一段时间了。虽然我发现 STL 更好，但我无法指出它的确切原因。一些推理，例如：
- 它需要 MFC：不成立，因为我的程序的其他部分使用 MFC
- 它是平台相关的：不成立，因为我仅在 Windows 上运行我的应用程序。（不需要可移植性）
- 它是在C++ 标准：好的，但是 MFC 容器仍然可以工作
我能想到的唯一原因是我可以在容器上使用算法。是否还有其他我在这里遗漏的原因 - 是什么让 STL 容器比 MFC 容器更好？
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 :
- It requires MFC: does not hold because other parts of my program uses MFC
- It is platform dependent: does not hold because I run my application only on windows.(No need for portability)
- 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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（13）
Ronald Laeremans，VC++ 产品部门经理，甚至说要使用 STL 2006 年 6 月：
但是，有一次我正在处理 Windows 安装阶段运行的一些代码时，我不被允许使用 STL 容器，但被告知要使用相反，ATL 容器（实际上特别是
CString，我猜它并不是真正的容器）。解释是，STL 容器依赖于运行时位，这些位在代码必须执行时实际上可能不可用，而 ATL 集合则不存在这些问题。这是一个相当特殊的场景，不会影响 99% 的代码。Ronald Laeremans, VC++ Product Unit Manager, even said to use STL in June 2006:
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
CStringin 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.STL 容器：
STL containers:
不过，使用 STL 以外的东西本质上并不是错误的。
Using something other than STL isn't inherently wrong though.
MFC 的一个好处是仍然有大量的 MFC 代码。其他答案讨论了第三方兼容性。不要忘记第三方基于 MFC 的东西。
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.
我总是更喜欢尽可能使用更多标准/兼容的库，因为我可能有未来的项目可以重用部分代码。我不知道未来的项目将使用哪些库，但如果我使用标准/兼容的东西，我就有更好的机会使我的代码可重用。
而且，我使用图书馆的次数越多，我就越能适应和更快地使用它。如果我要投入时间来学习一个库，我想确保它会保留下来并且不与特定的平台或框架绑定。
当然，我说所有这些都是假设我的选择在性能、功能和易用性方面非常相似。例如，如果 MFC 类在这些方面有足够显着的改进，我就会使用它们。
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.
事实上，您也可以在某些 MFC 容器上使用 STL 算法。然而，STL 容器是首选还有另一个非常实际的原因：许多第三方库（Boost、arabica、Crypto++、utf-cpp...）被设计为与 STL 一起使用，但对 MFC 容器一无所知。
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.
MFC 容器派生自
CObject，并且CObject将赋值运算符设为私有。我在实践中发现这非常烦人。std::vector、unlinke CArray，保证内存块是连续的，因此您可以轻松地与 C 编程接口进行互操作：MFC containers derive from
CObjectandCObjecthas 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:现在假设 C++ 开发人员至少对 STL 有点熟悉。对于 MFC 容器来说并非如此。因此，如果您要向团队中添加一名新开发人员，您将更容易找到了解 STL 而非 MFC 容器的开发人员，从而能够立即做出贡献。
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.
我认为这可以归结为一个简单的问题：你更信任谁？如果您信任 Microsoft，那么请继续使用 MFC 变体。如果你信任这个行业，那就使用STL。
我投票支持STL，因为今天在Windows 上运行的代码明天可能需要移植到另一个平台上。 :)
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. :)
在这种情况下，哪种工具适合您想做的工作，而“更好”是一个主观术语。
如果您需要将容器与其他符合标准的代码一起使用，或者如果代码要跨平台共享，那么 STL 容器可能是更好的选择。
如果您确定您的代码将保留在 MFC 领域，并且 MFC 容器可以为您工作，为什么不继续使用它们呢？
STL 容器本质上并不比 MFC 容器更好，但是由于它们是标准的一部分，因此在更广泛的上下文中更有用。
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.
除了提到的方面：良好支持、标准可用、性能优化、设计用于算法之外，我可能会添加另一个方面：类型安全和编译时检查负载。您甚至无法想象从
std::set中绘制一个double。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
doubleout of astd::set<int>.因为一个库使用迭代器将任何类型的序列与算法组合起来，以便 A) 所有合理的排列都是可能的，B) 它是普遍可扩展的，所以（当你考虑 15 年前的容器库概念时）这是一个令人惊叹的奇妙想法，在不到十年的时间里它几乎把其他一切都从水中吹了出来？
说真的，STL 有它的缺陷（为什么不用范围而不是迭代器？而且擦除-删除习惯并不完全漂亮），但它基于一个绝妙的想法，并且有很好的理由我们不需要学习新的容器/每次我们开始新工作时都会使用算法库。
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.
我不会完全驳回可移植性的论点。仅仅因为您现在使用 MFC 并不意味着您将永远使用 MFC。即使您主要为 MFC 编写，如果您的某些代码更通用且基于标准，也可以在其他应用程序中重复使用。
我认为考虑 STL 的另一个原因是它的设计和演变受益于以前的库，包括 MFC 和 ATL。许多解决方案更干净、更可重用并且更不易出错。 （尽管我希望他们有更好的命名约定。）
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.)