Question

以前，我曾经使用过MFC集合类CArray和CMap。过了一会儿，我换了STL容器，并且已经使用了一段时间。虽然我发现STL要好得多，但我无法明确指出它的确切原因。一些推理如：

它需要MFC：不能保留，因为我的程序的其他部分使用MFC
它依赖于平台：不成立，因为我只在Windows上运行我的应用程序。（不需要便携性）
它在C ++标准中定义：好的，但是MFC容器仍可正常工作

我能说出来的唯一原因是我可以在容器上使用算法。我在这里缺少任何其他原因 - 是什么让STL容器比MFC容器更好？

Answer 1

2006年6月，VC ++产品部经理Ronald Laeremans甚至said to use STL：

坦率地说，团队会给你相同的答案。 MFC集合类仅用于向后兼容。 C ++有一个集合类标准，那就是Standards C ++ Library。在MFC应用程序中使用任何标准库都没有技术缺陷。

我们不打算在这方面做出重大改变。

Ronald Laeremans
代理产品部经理
Visual C ++团队

但是，在我正在处理在Windows安装阶段运行的某些代码的某个时刻，我不允许使用STL容器，但被告知要使用ATL容器（实际上CString ，我猜这不是一个容器）。解释是，STL容器对运行时位具有依赖性，这些位在代码必须执行时可能实际上不可用，而ATL集合不存在这些问题。这是一个相当特殊的场景，不应该影响99％的代码。

Answer 2

STL容器：

有性能保证
可用于STL算法，它也具有性能保证
可以被第三方C ++库（如Boost
是标准的，可能比专有解决方案更长久
鼓励算法和数据结构的通用编程。如果您编写符合STL的新算法和数据结构，您可以免费使用STL提供的内容。

Answer 3

在语法，互操作性和范例方面与其他库（例如boost）的兼容性。这是一项非常重要的好处。
使用STL将开发一种在其他环境中更有用的技能组合。 MFC不再广泛使用; STL是。
使用STL会产生一种心态，你可能（或可能不会）在你自己编写的代码中找到有用的东西。

使用STL以外的东西本身并不是错误的。

Answer 4

STL拥有比MFC更多的集合类型
Visual Studio（2008+）调试器可以比MFC更好地显示STL。（AUTOEXP.DAT魔术可以解决这个问题 - 但这很痛苦！没有什么比调试你的调试器了。 ..）

MFC的一个好处是，那里仍然有大量的MFC代码。其他答案谈论第三方兼容性。不要忘记第三方基于MFC的东西。

Answer 5

我总是喜欢使用更多的标准/兼容库，因为我可能有将来可以重用部分代码的项目。我不知道未来的库将使用什么库，但如果我使用标准/兼容的东西，我有更好的机会让我的代码可重用。

此外，我使用的库越多，我就越舒服，越快。如果我打算花时间去学习图书馆，我想确保它能够保持不变并且与特定的平台或框架无关。

当然，我说所有这些都假设我的选择在性能，功能和易用性方面非常相似。例如，如果MFC类在这些方面有足够的改进，我会改用它们。

Answer 6

事实上you can use STL algorithms on some of MFC containers as well。但是，STL容器是另一个非常实用的首选容器：许多第三方库（Boost，arabica，Crypto ++，utf-cpp ......）设计用于STL，但对MFC容器一无所知。

Answer 7

MFC容器派生自CObject，CObject将赋值运算符设为私有。我在实践中发现这非常烦人。

std::vector， ~~unlinke CArray~~ ，保证内存块是连续的，因此您可以轻松地与C编程接口互操作：

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

Answer 8

现在假设C ++开发人员至少熟悉STL。 MFC容器不是这样。因此，如果您要向团队添加新的开发人员，您将更容易找到知道STL而不是MFC容器的人，因此能够立即做出贡献。

Answer 9

我认为这归结为一个简单的问题：你更信任谁？如果您信任Microsoft，则继续使用MFC变体。如果您信任该行业，请使用STL。

我投票支持STL，因为今天在Windows上运行的代码可能需要明天移植到另一个平台。：）

Answer 10

这是一个案例，无论哪种工具适用于您想要的工作，并且“更好”是一个主观术语。

如果您需要将容器与其他符合标准的代码一起使用，或者它将成为跨平台共享的代码，那么STL容器可能是更好的选择。

如果您确定您的代码将保留在MFC-land中，并且MFC容器适合您，为什么不继续使用它们？

STL容器本身并不比MFC容器好，但由于它们是标准的一部分，因此它们在更广泛的环境中更有用。

Answer 11

因为一个库使用迭代器将任何类型的序列与算法结合起来，以便A）所有合理的排列都是可能的，并且B）它是普遍可扩展的（当你考虑到你的容器库的概念，因为它是15年这是一个令人惊叹的奇妙想法，它在不到十年的时间内几乎被其他所有东西吹走了？

说真的，STL有它的缺点（为什么不是范围而不是迭代器？并且删除 - 删除成语并不完全相同），但它基于一个绝妙的想法，我们不需要学习一个很好的理由每次我们开始新工作时都会有新的容器/算法库。

Answer 12

接下来提到的方面：支持良好，标准可用，针对性能进行了优化，设计用于算法，我可能还会增加一个方面：类型安全性和大量编译时检查。您甚至无法想象从double中绘制std::set<int>。

Answer 13

我不会完全忽略可移植性论点。仅仅因为你今天使用MFC并不意味着你永远都会。即使您主要为MFC编写代码，如果某些代码更通用且基于标准，也可以在其他应用程序中重复使用。

我认为考虑STL的另一个原因是它的设计和发展受益于之前的库，包括MFC和ATL。因此，许多解决方案更清晰，更易于使用，并且不易出错。（虽然我希望他们有更好的命名惯例。）

为什么STL容器比MFC容器更受欢迎？

13 个答案: