C++ 标准库和 Boehm 垃圾收集器答案

【问题标题】：C++ standard library and Boehm garbage collectorC++ 标准库和 Boehm 垃圾收集器
【发布时间】：2011-12-22 10:47:07
【问题描述】：

我想在带有 GCC 的 Linux/AMD64/Debian 上开发一个多线程 C++ 应用程序（最终大部分 C++ 代码将由应用程序本身生成，可以被视为高级域特定语言） 4.6（可能是最新的 C++11 标准）。

我真的很想使用Boehm's conservative garbage collector 来分配我的所有堆，因为我想使用new(GC) 进行分配，并且永远不用担心delete。我假设 Boehm 的 GC 运行良好。

使用 C++（而不是 C）的主要动机是 C++ 标准库提供的所有算法和集合 std::map ... std::vector。

Boehm 的 GC 提供了一个 gc_allocator<T> 模板（在其文件 gc/gc_allocator.h 中）。

我应该将operator ::new 重新定义为 Boehm 的吗？

或者我应该使用所有集合模板，并将显式分配器模板参数设置为某个gc_allocator？我不完全理解第二个模板参数（分配器）对std::vector 的作用？是用于分配向量内部数据，还是分配每个单独的元素？

那么std::string-s 呢？如何让他们的数据被 GC 分配？我应该有自己的字符串，使用basic_string 模板和gc_allocator 吗？有没有办法让分配给GC_malloc_atomic而不是GC_malloc的char的内部数组？

或者您是否建议不要将 Boehm GC 与 g++ 编译的应用程序一起使用？

问候。

【问题讨论】：

这完全取决于您对 C++ 的熟悉程度和擅长程度。你能在不使用delete 的情况下编写一个像样的C++ 程序吗？你是否意识到new 只能在非常非常特殊的情况下使用，并且大多数情况下不需要指针？如果您了解所有这些并得出结论认为您需要垃圾收集器，那么请务必继续。另一方面，如果您不这样做，您可能会发现惯用的现代 C++ 在用户友好的确定性内存管理方面非常出色。
呵呵——我可能在这里有点不合时宜，但在我看来，如果你确实知道垃圾收集但不知道C++ 很好，那么这就是经典的“我有锤子”的情况……为什么不贴一个典型的 sn-p 代码，我们可以看看如何用 C++ 的方式来做呢？
嗯。你真的必须选择一个。它们是不同的语言。当您生成 C++ 代码并正确执行时，我会说您不需要垃圾收集器，而您可以证明为什么您会需要一个垃圾收集器。（你的编译器可能会使用一个，但我现在谈论的是生成的代码。）
坦率地说，我认为问题太多了。最好是专注和具体的。老实说，如果您对 C++ 分配器机制不满意，那么设计 C++ 代码生成工具可能还为时过早，您应该彻底掌握要翻译的语言，然后再使用冒险。这只是我个人的印象，我祝你好运和勇气——我只是认为学习更多的 C++ 一段时间对每个人来说都是双赢的。
简单地说，完全没有理由直接使用new，并且从不有理由使用delete 任何东西。从你的帖子来看，我给我留下的印象是你完全不知道如何编写 C++ 代码，也不使用作为标准提供的构造，并且使用 GC 仅仅是因为它是你习惯的范式。

标签： c++ linux garbage-collection g++

【解决方案1】：

为了部分回答我自己的问题，下面的代码

// file myvec.cc
#include <gc/gc.h>
#include <gc/gc_cpp.h>
#include <gc/gc_allocator.h>
#include <vector>

class Myvec {
  std::vector<int,gc_allocator<int> > _vec;
public:
  Myvec(size_t sz=0) : _vec(sz) {};
  Myvec(const Myvec& v) : _vec(v._vec) {};
  const Myvec& operator=(const Myvec &rhs) 
    { if (this != &rhs) _vec = rhs._vec; return *this; };
  void resize (size_t sz=0) { _vec.resize(sz); };
  int& operator [] (size_t ix) { return _vec[ix];};
  const int& operator [] (size_t ix) const { return _vec[ix]; };
  ~Myvec () {};
};

extern "C" Myvec* myvec_make(size_t sz=0) { return new(GC) Myvec(sz); }
extern "C" void myvec_resize(Myvec*vec, size_t sz) { vec->resize(sz); }
extern "C" int myvec_get(Myvec*vec, size_t ix) { return (*vec)[ix]; }
extern "C" void myvec_put(Myvec*vec, size_t ix, int v) { (*vec)[ix] = v; }

当使用g++ -O3 -Wall -c myvec.cc 编译时，会生成一个带有

的目标文件

 % nm -C myvec.o
                 U GC_free
                 U GC_malloc
                 U GC_malloc_atomic
                 U _Unwind_Resume
0000000000000000 W std::vector<int, gc_allocator<int> >::_M_fill_insert(__gnu_cxx::__normal_iterator<int*, std::vector<int, gc_allocator<int> > >, unsigned long, int const&)
                 U std::__throw_length_error(char const*)
                 U __gxx_personality_v0
                 U memmove
00000000000000b0 T myvec_get
0000000000000000 T myvec_make
00000000000000c0 T myvec_put
00000000000000d0 T myvec_resize

所以生成的代码中没有普通的 malloc 或 ::operator new。

因此，通过使用gc_allocator 和new(GC)，我显然可以确定在我不知情的情况下不会使用普通的::opertor new 或malloc，并且我不需要重新定义::operator new

附录（2017 年 1 月）

供将来参考（感谢 Sergey Zubkov 在Quora 的评论中提到它），另请参阅n2670 和<memory> and garbage collection support（如std::declare_reachable、std::declare_no_pointers、std::pointer_safety 等...） .但是，至少在当前的 GCC 或 Clang 中，这还没有实现（除了以微不足道但可接受的方式使其成为无操作）。

【讨论】：