2

在尝试跟上 C++ 的速度（来自 C 的长期经验）时，我显然在尝试做正确的事情，并尽可能多地使用标准。

然而，在我对此事的阅读中，我遇到了很多对标准事物的批评和对非标准事物的赞扬。例如，即使（我认为）考虑不周的 MFC 库也有一些功能，例如，它的CString类中一些人认为它足够有用，可以使他们继续使用它，尽管它是（a）非标准的并且（b）它（我假设，从大量的批评中）在许多重要方面都有缺陷。

我的问题是双重的，那么：

A. 哪些库是考虑不周的，包含的特性仍然值得继续使用，这些特性是什么，它们有什么好处？

B. 是否有“适配器”库可以简化和/或加强此类库的使用，例如提供抽象资源泄漏的良好接口、从非 STL 库接口到 STL 的适配器等等

作为 StackOverflow 的相对新手，我不能 100% 确定这个问题是否足够准确，所以如果它过于开放，我会提前道歉。

提前致谢

4

4 回答 4

2

IMO 关于 MFC 最好的一点是，从历史上看，它在 STL 可用之前就已经可用，有总比没有好。

如果您正在编写与现有 MFC 代码库兼容的代码，MFC 仍然很好。

除此之外，MFC 几乎没有什么优点，只是它可能仍然是（如果不是最明显的）Windows 的 C++ 类库之一。

于 2009-05-23T03:24:14.390 回答
2

我个人的 grunge 是ACE。有点相反——好主意，当时没有其他东西可用于 C++ 中的跨平台线程和网络开发、广泛部署、图书馆作者的书籍等。但是实现很糟糕，使用模式复杂，几乎所有 C++ 有用的特性都被压制了（或者当时不存在）。我认为仅这个库就导致很多人认为 C++ 既难看又难看。最近提升collection 开始赶上线程、ipc 和网络，所以至少有一个替代方案。但话虽如此，我仍然认为如果你在那个领域熟悉 ACE 是值得的，因为太多人使用它，想法很好，它可以作为图书馆设计的一个很好的反面例子。

于 2009-05-23T05:12:05.457 回答
1

更笼统地说，我认为人们坚持使用旧的、笨拙的甚至可能是过时的库的原因之一是他们已经习惯了它，任何新的和闪亮的东西可能会做得更好，但最初更难掌握/理解。因此，您可以使用熟悉的内容并保持生产力。

我认为这是完成工作和“正确”完成工作之间的平衡。介于两者之间的某个地方可能是我们大多数人最终的结局。

于 2009-05-23T09:25:37.460 回答
0

我认为 CString 是非标准的，因为 MFC 不是跨平台的。std::string() 是标准的，但如果我们使用一切标准，那么为什么 MS 开发 MFC？

于 2009-05-23T03:20:33.757 回答