以前，我曾经使用MFC的集合类CArray和CMap 。 过了一会儿，我切换到STL容器，并一直使用他们的一段时间。 虽然我觉得STL好多了，我无法针点确切的原因吧。 一些理由，如：
唯一的原因，我能想出的是，我可以在容器使用的算法。 有没有，我很想念这里的任何其他原因-是什么让STL容器比MFC容器更好 ？
罗纳德Laeremans，VC ++产品部经理，甚至说要用STL在2006年6月：
坦率地说球队会给你同样的答案。 MFC的集合类是只存在向后兼容性。 C ++对集合类标准，并且是标准C ++库。 没有为MFC应用程序使用任何标准库中没有任何技术缺陷。
我们不打算做这方面的显著变化。
罗纳德Laeremans
代理产品部经理
VISUAL C ++团队
然而，在一个点上我在那里工作的一些代码中的Windows安装阶段跑，我是不允许使用STL容器，但被告知使用ATL容器代替（其实CString特别，我猜是不是真正的容器）。 的解释是，STL容器对运行时位可能不实际获得当时的代码必须执行依赖条件，而对ATL的集合不存在这些问题。 这是一个比较特殊的情况下，不应该影响到99％的代码在那里。
STL容器：
使用非STL其他东西本质上不是错的。
用MFC一个好处是，仍然存在的MFC代码的大型语料库在那里。 其他答案谈论第三方兼容性。 不要忘了第三方基于MFC的东西。
我总是喜欢使用更标准/兼容库，在那里我可以，因为我可以有我可以重用的代码的一部分未来的项目。 我不知道未来的库项目将使用，但我必须让我的代码可重用的，如果我使用标准的/兼容的东西更好的机会。
此外，更多的我使用一个库，我得到更舒适，用它更快。 如果我要投入时间去学习库，我想确保它会呆在身边，而不是与特定的平台或框架捆绑英寸
当然，我说这一切的假设，我的选择是相当类似的，当涉及到性能，功能和易用性。 举例来说，如果MFC类是在这些领域显著足够的改善，我反而使用它们。
事实上，你可以在某些MFC容器的使用STL算法以及 。 然而，STL容器是优选的另一个很实际的理由：许多第三方库（升压，小粒的，Crypto ++，UTF-CPP ...）的设计与STL的工作，但一无所知MFC容器。
现在假定是C ++开发人员至少passingly熟悉STL。 不是这样的MFC容器。 所以，如果你添加一个新的开发者给你的团队，你将有更容易找到一个谁知道STL比MFC容器，因此将能够立即作出贡献。
MFC容器派生自CObject和CObject有一个由私人赋值运算符。 我发现这实际上很烦人。
std::vector ，unlinke CARRAY，保证了存储块是连续的，因而可以很容易地用C编程接口互操作：
std::vector<char> buffer;
char* c_buffer = &*buffer.begin();
我认为它归结为一个简单的问题：你信任谁吗？ 如果你信任微软，然后继续使用MFC的变种。 如果您信任的行业，然后使用STL。
我投了STL，因为今天在Windows上运行的代码可能需要移植到另一个平台的明天。 :)
这是任何一个工具，你想要做的工作作业的情况下，和“更好”是一个主观的术语。
如果您需要与其他符合标准的代码使用的容器，或者如果它永远会是跨平台共享代码，STL容器可能是一个更好的选择。
如果你确信你的代码将保持在MFC-土地，和MFC容器为你工作，为什么不继续使用它们？
STL容器不是固有比MFC容器更好，然而，因为它们是它们是在更广阔的范围内上下文的更有用的标准的一部分。
接下来所提到的几个方面：良好支持，提供标准，优化了性能，设计与算法的使用，我可能会添加更多的一个方面：类型安全，和编译时检查的负荷。 你甚至无法想象绘制double出的std::set<int> 。
由于使用迭代器库与算法序列结合任何类型的，这样A）所有合理的排列是可能的，B）这是普遍可扩展的，是（当你想想你的容器库的概念，因为它是15年前）等一记blowingly奇妙的想法，那它几乎吹出来的水都在不到十年的别的？
严重的是，STL有其缺陷（为什么不是范围，而不是迭代器？和擦除remove惯用法是不完全漂亮），但它是基于一个绝妙的主意，并有我们不需要学习一个新的容器很好的理由/算法库每次我们在新的工作岗位开始时间。
我不会完全关闭该便携性的说法。 仅仅因为你使用MFC今天并不意味着你总是会。 而且，即使你大多写MFC，一些你的代码可以在其他应用程序重复使用，如果它是更通用的和基于标准的。
我觉得其他理由认为STL的是，它的设计和演变，已经从已经来过了库中受益，包括MFC和ATL。 因此，许多解决方案都更加清洁，可重复使用，且不易出错。 （虽然我希望他们有一个更好的命名约定。）
