C++ 为什么STL容器优于MFC容器？
以前，我使用MFC集合类，例如C++ 为什么STL容器优于MFC容器？,c++,mfc,stl,containers,C++,Mfc,Stl,Containers,以前，我使用MFC集合类，例如CArray和CMap。过了一段时间，我切换到STL容器，并已经使用了一段时间。虽然我发现STL好得多，但我无法指出它的确切原因。其中一些原因，例如： 它需要MFC:不起作用，因为我的程序的其他部分使用MFC 它依赖于平台：不适用，因为我只在windows上运行应用程序。（不需要可移植性） 是在C++标准中定义的：OK，但是MFC容器仍然工作 我能想到的唯一原因是我可以在容器上使用算法。我在这里遗漏了其他原因吗？是什么让STL容器比MFC容器更好？事实上。然而，由于
CArrayCMap我能想到的唯一原因是我可以在容器上使用算法。我在这里遗漏了其他原因吗？是什么让STL容器比MFC容器更好？事实上。然而，由于另一个非常实际的原因，STL容器是首选的：许多第三方库（Boost、arabica、Crypto++、utf cpp…）设计用于STL，但对MFC容器一无所知。这是一个适用于任何工具的情况，而“更好”是一个主观术语 如果您需要将容器与其他符合标准的代码一起使用，或者需要跨平台共享代码，那么STL容器可能是更好的选择 如果您确信您的代码将保留在MFC领域，并且MFC容器为您工作，那么为什么不继续使用它们呢 STL容器本身并不比MFC容器好，但由于它们是标准的一部分，因此在更广泛的环境中更有用。STL容器：
- 有性能保证吗
- 可用于STL算法，该算法也有性能保证
- 可以通过Boost 的第三方C++库来利用
- 是标准的，并且可能比专有解决方案更有效
- 鼓励对算法和数据结构进行通用编程。如果您编写符合STL的新算法和数据结构，您可以免费利用STL已经提供的功能
- 在语法、互操作性和范例方面与其他库（如boost）的兼容性。这是一个不小的好处
- 使用STL将开发出一套在其他环境中更可能有用的技能。MFC的应用不再那么广泛；STL是
- 使用STL将培养一种思维方式，您可能会（也可能不会）在自己编写的代码中发现这种思维方式是有用的
但是，使用STL以外的东西本身并不是错误的。VC++产品部门经理Ronald Laeremans，即使在2006年6月： 坦率地说，团队会给你同样的答案。MFC集合类仅用于向后兼容。C++有一个标准集合类，也就是标准C++库。在MFC应用程序中使用任何标准库都没有技术缺陷 我们不打算在这方面作出重大改变 < Ronald Laeremans >代理产品单元管理器BR> Visual C++团队
然而，有一次我正在编写Windows安装阶段运行的一些代码，不允许我使用STL容器，而是被告知使用ATL容器（实际上是
CString我投票支持STL，因为今天在Windows上运行的代码明天可能需要移植到另一个平台上。：） 我总是喜欢在可能的地方使用更标准/兼容的库，因为我将来可能会有一些项目可以重用部分代码。我不知道未来的项目将使用什么库，但如果我使用标准/兼容的东西，我有更好的机会使我的代码可重用 而且，我使用图书馆的次数越多，我使用图书馆就越舒服，速度也越快。如果我打算花时间学习一个图书馆，我想确保它不会被某个特定的平台或框架所束缚 当然，我说所有这些都是假设我的选择在性能、特性和易用性方面非常相似。例如，如果MFC类在这些方面有足够大的改进，我会使用它们。
- STL的集合类型比MFC多
- Visual Studio（2008+）调试器比MFC更好地可视化STL。（AUTOEXP.DAT magic可以解决这一问题-但这是一件痛苦的事情！没有什么比在调试器出错时调试它更痛苦了…）
MFC的一个优点是仍然有大量的MFC代码。其他答案谈到了第三方兼容性。不要忘记基于第三方MFC的内容。MFC容器派生自
CObjectCObjectstd:：vectorstd::vector<char> buffer;
char* c_buffer = &*buffer.begin();
std:：向量缓冲区；
char*c_buffer=&*buffer.begin（）；