Question

我正在尝试使用共享库来构建模块化程序。

要编译两个cpp文件：

共享库，使用

进行编译

g ++ -fPIC -shared module.cpp -o module.so

//module.cpp
#include <iostream>

使用共享库的文件，使用

进行编译

g ++ src / main.cpp -ldl -o binary

或

g ++ -DFIX src / main.cpp -ldl -o binary

//main.cpp
#include <dlfcn.h>
#ifdef FIX
# include <iostream>
#endif

int main()
{
   void* h = dlopen("./module.so", RTLD_LAZY);
   if ( h )
   {
      dlclose(h);
   }
}

在FIX未定义的情况下，valgrind会报告许多仍然可访问的内存（5,373bytes），并且定义了FIX，没有内存泄露。

在共享库中使用iostream有什么问题？

g ++ - 4.6，g ++ - 4.7和g ++ - 4.8会出现此问题。 g ++ - 4.4不显示此行为。遗憾的是，我没有其他编译器可以测试（我不想因此而切换到g ++ - 4.4）。

更新

使用附加标志-static-libstdc++ -static-libgcc编译共享库文件可以减少泄漏块的数量，但不会完全减少。仅-static-libgcc无效，-static-libstdc++会产生一些影响，但不会同时产生影响。

Answer 1

1。此代码段为何或如何“修复”此问题？

我不确定为什么不深入研究libstdc ++代码，但我认为iostreams库分配的内存（在整个程序的持续时间内保持分配）被valgrind报告为问题。在共享库中分配，但在主程序中分配时不会。

2。什么等价的，独立的（来自标准库）代码片段提供相同的错误修复？

首先，当仍然可以通过标准库分配时，我不知道为什么你想要“独立于标准库”的东西。修复程序要么根本不使用标准库，要么，或者以不同方式使用它。

其次，“修复”是未定义的行为，因为您通过以不同方式重新定义std::ios_base到std lib中的正确定义来违反单定义规则。

获取相同行为的正确方法是#include <iostream>文件中的main.cpp，包括<iostream>定义static std::ios_base::Init对象。或者，只需#include <ios>然后定义static变量（但不要重新定义std::ios_base类型），但这基本上是<iostream>所做的，所以你不妨使用它

内存仍然可以修复错误，但为什么？

1 个答案: