GCC/Windows DLLs/C++ STL 前端有什么改进吗？答案

【问题标题】：Any improvements on the GCC/Windows DLLs/C++ STL front?GCC/Windows DLLs/C++ STL 前端有什么改进吗？
【发布时间】：2009-02-04 19:13:57
【问题描述】：

昨天，在 Cygwin 下使用 GCC 编译的 DLL 时，我遇到了一个相当烦人的崩溃。基本上，一旦您使用调试器运行，您最终可能会陷入由 RtlFreeHeap() 接收到它未分配的地址所引起的调试陷阱。

这是 Cygwin 上的 known bug with GCC 3.4。出现这种情况是因为 libstdc++ 库包含针对空字符串的“聪明”优化。我为您省去了细节（请参阅本文中的参考资料），但是每当您在一个 DLL 中为“属于”另一个 DLL 的 std::string 对象分配内存时，您最终都会给一个堆释放一个来自另一个堆。因此 RtlFreeHeap() 中的 SIGTRAP。

当跨 DLL 边界引发异常时，还会报告其他问题。

一旦您的项目基于 DLL 和 STL，这会使 Windows 上的 GCC 3.4 成为不可接受的解决方案。我有几个选项可以跳过这个选项，其中许多都非常耗时和/或烦人：

我可以patch my libstdc++或rebuild it with the --enable-fully-dynamic-string配置选项
我可以改用静态库，这会增加我的链接时间

我也不能（还）切换到另一个编译器，因为我正在使用一些其他工具。我从一些 GCC 人那里找到的 cmets 是“几乎从未报道过，所以这可能不是问题”，这让我更加恼火。

有人有这方面的消息吗？除了@987654324 上的一条评论外，我找不到任何明确的声明表明已修复（该错误仍标记为“已分配”） @。

谢谢！

【问题讨论】：

老实说，如果有人使用我正在维护的旧版本的编译器，并且报告了一个几乎没有其他人报告（已知或不知道）的错误，我可能会有同样的反应。我不认为商业编译器团队会做任何不同的事情。
好点！问题是，在 Cygwin 上，GCC 3 仍然是官方编译器，GCC 4.3.2 可作为“alphaware”使用。我现在正在走这条路，但我有点沮丧，因为 Windows 被 GCC 社区视为二等平台。

标签： c++ string dll gcc libstdc++

【解决方案1】：

您遇到的一般问题是，C++ 从来就不是真正意义上的组件语言。它实际上是为创建完整的独立应用程序而设计的。诸如共享库和其他此类机制之类的东西是由供应商自己创建的。想想这个例子：假设您创建了一个返回 C++ 对象的 C++ 组件。 C++ 组件如何知道它将被 C++ 调用者使用？如果调用者是一个 C++ 应用程序，为什么不直接使用这个库呢？

当然，以上信息对你并没有真正的帮助。

相反，我会创建共享库/DLL，以便您遵循一些规则：

由组件创建的任何对象也会被同一个组件销毁。
当所有创建的对象都被销毁时，可以安全地卸载组件。

您可能必须在您的组件中创建额外的 API 以确保这些规则，但通过遵循这些规则，它将确保不会发生上述问题。

【讨论】：

哦，我多么希望我在大约十五年前有一次有这种洞察力，当时我正试图使用 C++ 作为一种组件制作语言！
@Tommy：我实际上并没有尝试将 C++ 用作组件语言，我只是想将我的项目拆分为单独的 DLL，以减少开发的编译和链接时间。 GCC 3 是我的供应商，但它没有做好它的工作，因为它会在 Windows 上创建损坏的 DLL。
@Carl：如果不仅仅是一个二进制应用程序，那么还有一个组件。 DLL（动态链接库）是一个组件，类似于 Linux 上的共享对象。不管你是否意识到，这都是一个组件。