31

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

  1. 它需要 MFC：不成立，因为我的程序的其他部分使用 MFC
  2. 它取决于平台：不成立，因为我只在 Windows 上运行我的应用程序。（不需要可移植性）
  3. 它在 C++ 标准中定义：好的，但是 MFC 容器仍然可以工作

我能想到的唯一原因是我可以在容器上使用算法。还有什么我在这里遗漏的其他原因 - 是什么让 STL 容器比 MFC 容器更好？

4

13 回答 13

47

VC++ 产品部门经理 Ronald Laeremans 甚至在 2006 年 6 月说要使用 STL：

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

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

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

然而，有一次我正在编写一些在 Windows 安装阶段运行的代码，我被禁止使用 STL 容器，但被告知要使用 ATL 容器（实际上CString特别是，我猜这不是真的）一个容器）。解释是 STL 容器依赖于运行时位，这些位在代码必须执行时可能实际上不可用，而 ATL 集合不存在这些问题。这是一个相当特殊的场景，不应该影响 99% 的代码。

于 2009-08-28T16:34:26.090 回答
36

STL 容器：

  • 有性能保证
  • 可用于同样有性能保证的 STL 算法
  • 可以被 Boost 等第三方 C++ 库利用
  • 是标准的，并且可能比专有解决方案寿命更长
  • 鼓励对算法和数据结构进行通用编程。如果您编写符合 STL 的新算法和数据结构，您可以免费利用 STL 已经提供的功能。
于 2009-08-28T16:30:41.370 回答
23
  • 在语法、互操作性和范式方面与其他库（如 boost）的兼容性。这是一个不平凡的好处。
  • 使用 STL 将开发一种在其他情况下更有可能有用的技能。MFC 不再被广泛使用。STL 是。
  • 使用 STL 将培养一种思维方式，您可能会（或可能不会）发现在您自己编写的代码中有用。

不过，使用 STL 以外的东西本质上并不是错误的。

于 2009-08-28T16:33:13.143 回答
8
  • STL 的集合类型比 MFC 多
  • Visual Studio (2008+) 调试器比 MFC 更好地可视化 STL。（AUTOEXP.DAT 魔法可以解决这个问题 - 但它很痛苦！当你把它搞砸时，没有什么比调试你的调试器更好了......）

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

于 2009-08-28T16:47:17.390 回答
6

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

此外，我使用图书馆的次数越多，我就越舒服、越快。如果我打算花时间学习一个库，我想确保它能够一直存在并且不与特定的平台或框架绑定。

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

于 2009-08-28T16:45:38.547 回答
5

事实上，您也可以在某些 MFC 容器上使用 STL 算法。然而，首选 STL 容器还有一个非常实际的原因：许多第三方库（Boost、arabica、Crypto++、utf-cpp...）旨在与 STL 一起使用，但对 MFC 容器一无所知。

于 2009-08-28T16:29:43.040 回答
5

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

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

std::vector<char> buffer; 
char* c_buffer = &*buffer.begin();
于 2009-08-28T16:47:53.660 回答
4

现在假定 C++ 开发人员至少对 STL 非常熟悉。MFC 容器并非如此。因此，如果您要为您的团队添加新的开发人员，您将更容易找到了解 STL 的人而不是 MFC 容器，从而能够立即做出贡献。

于 2009-08-28T19:26:38.943 回答
3

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

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

于 2009-08-28T16:34:45.637 回答
2

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

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

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

STL 容器在本质上并不比 MFC 容器好，但是由于它们是标准的一部分，它们在更广泛的上下文中更有用。

于 2009-08-28T16:30:20.123 回答
2

因为使用迭代器将任何类型的序列与算法相结合的库，因此 A）所有合理的排列都是可能的，并且 B）它是普遍可扩展的，（当您考虑 15 年前的容器库概念时）是这样的一个令人兴奋的奇妙想法，在不到十年的时间里，它几乎把其他所有东西都从水中吹走了？

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

于 2009-08-28T17:17:42.477 回答
2

在提到的方面：良好支持、标准可用、性能优化、设计用于算法，我可能会添加更多方面：类型安全和大量编译时检查。你甚至无法想象double从std::set<int>.

于 2009-08-28T17:24:51.963 回答
2

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

我认为考虑 STL 的另一个原因是它的设计和演变受益于以前出现的库，包括 MFC 和 ATL。许多解决方案更清洁、更可重用且不易出错。（虽然我希望他们有更好的命名约定。）

于 2009-08-28T19:12:02.653 回答