c++ - 在设计和体系结构上开发像.NET Framework 类库的非托管C++ 库是否浪费时间？

Question

有很多 C++ 类库，要么是开源的，要么是商业的，比如 MFC、ATL、SmartWin++，QT。但它们都没有 .NET 框架类库的设计、体系结构和纯度。实现类似于 .NET 框架类库并为开发人员提供广泛功能的 C++ 库的想法如何，当然该库将是非托管的，并将包装 win32 API 和 COM

Answer 1

有趣的问题。但我认为为非托管 C++ 重新创建 .NET BCL(基类库)要么是浪费时间，要么不是最佳选择。这是为什么？

1. C++ 语言与 .NET 语言有很大不同。这意味着，如果您要为 C++ 重写 BCL，您将最佳地尝试充分利用 C++。这可能会导致完全不同的框架设计:

   • IDisposable 和 Close 方法不是必需的，因为 C++ 提供确定性的对象释放和拆卸；类似于 using block ，但更通用。 (相关的 C++ 概念是作用域、自动存储、RAII 和智能指针类。)也就是说，C++ BCL 在这方面有可能实现更优雅的设计。

   • C++ 模板与 .NET 泛型有很大不同。 C++ 也没有委托(delegate)或事件(尽管您可能会模仿这些)。反射和运行时类型以及代码生成也不能轻松地与 C++ 一起使用。最后，C++(C++0x 之前)不支持 lambda 函数。这意味着 BCL 的更现代的添加在 C++ 中可能不得不看起来完全不同。

2. BCL 中有些东西已经过时，或者如果您今天设计 BCL，结果会大不相同。让我们以 System.Reflection 为例。 BCL 的这一部分是在引入泛型之前构建的。如果今天从头开始重写，反射很可能会利用泛型，从而提高类型安全性。

3. 如您所见，新的 C++ 版本的 BCL 很可能最终会与它所基于的 .NET BCL 大不相同；所以您应该想知道是否有必要在 .NET BCL 上建立这样一个新库。你甚至需要一个单一的框架，还是最终开发单独的库更容易？一种用于网络，一种用于抽象数据类型，一种用于 GUI，一种用于反射等。

   • 独立库的缺点是它们可能没有一致的 API 设计。因此，使用一个库的经验根本无法帮助您学习另一种 API。

   • 因此，单独的库更易于维护。例如，您可以维护反射库，而无需与 GUI 库维护人员协调每个操作。

   • 单独的库的优势在于，如果您找到更清洁、更快或更好的替代品，您可以将一个库换成另一个库。

4. 即使有人编写了 BCL 的 C++ 版本——从长远来看，维护这样一个库也需要大量资源，当您认为它应该独立于平台时更是如此。微软拥有这种能力和这些资源。你也会吗？

一个伟大的库对一切的诱惑确实是一个 API 的一致性，以及“每个人”都会使用它的事实。但我认为，即使您编写了这样一个 C++ BCL，您也会发现很难接触到几乎所有 C++ 程序员并说服他们使用您的库。