Garbage collection Libraries in C++ [closed]

2019-01-10 07:50发布

问题:

What free and commercial garbage collection libraries are available for C++, and what are the pros and cons of each?

I am interested in hard-won lessons from actual use in the field, not marketing or promotional blurb.

There is no need to elaborate on the usual trade offs associated with automatic garbage collection, but please do mention the algorithms used (reference counting, mark and sweep, incremental, etc.) and briefly summarise the consequences.

回答1:

I have used the Boehm collector in the past with good success. It's open source and can be used in commercial software.

It's a conservative collector, and has a long history of development by one of the foremost researchers in garbage collection technology.



回答2:

Boost has a great range of smart pointers which impliment reference counting or delete-on-scope exit or intrusive reference counting. These have proven enough for our needs. A big plus is that it is all free, open source, templated C++. because it is reference counting, in most cases it is highly deterministic when an object gets destroyed.



回答3:

The Boehm garbage collector is freely available, and supposedly rather good (no first hand experience myself)

([PDF WARNING]Theoretical paper about C++0x proposal for the Boehm garbage collector)

It was originally said to make C++0x , but will not make it after all (due to time constraints I suppose).

Proprosal N2670 (minimal support for garbage collectors) did get approved in june 2008 though, so as compiler implementations pick up on this, and the standard gets finalised, the garbage collection world out there for C++ is sure to change...



回答4:

I use boehm-gc a lot. It is straight-forward to use, but the documentation is really poor. There is a C++ page, but its quite hard to find.

Basically, you just make sure that every class inherits from their base class, and that you always pass gc_allocator to a container. In a number of cases you want to use libgccpp to catch other uses of new and delete. These are largely high-level changes, and we find that we can turn off the GC at compile-time using an #ifdef, and that supporting this only affects one or two files.

My major problem with it is that you can no longer use Valgrind, unless you turn the collector off first. While turning the collector off is easy to do, and doesn't require recompiling, it's obviously impossible to use it if you start to run out of memory.



回答5:

The only one I know of is Boehm, which at the bottom is a traditional mark and sweep. It probably uses various techniques to optimize this, but typically incremental/generational/compacting GC's will be hard to create for C++ without going for a managed subset such as what you can get with .Net C++. Some of the approaches that needs to move pointers can be implemented with compiler support for pinning pointers or read/write blocks though, but the effect on performance may be too big, and it isn't necessarily non-trivial changes to the GC.



回答6:

The major difficulty with GC's in C++ is the need to handle uncooperative modules, in the GC sense. ie, to deal with libraries that were never written with GC's in mind.

This is why the Boehm GC is often suggested.



回答7:

Here's a commercial product I found in just looking for this same thing

HnxGC http://hnxgc.harnixworld.com/

Back in the day, there was also a product called Great Circle from Geodesic Systems, but doesn't look like they sell that anymore. No idea if the sold the product to anyone else.



回答8:

You can also use Microsoft's Managed C++. The CLR and the GC are very solid and used in server products, but you have to use CLR types for the GC to actually collect - you can't just recompile your existing code and remove all the delete statements.

I would rather use C# to write brand new code, but Managed C++ lets you evolve your code base in a more progressive manner.



回答9:

Read this and take a good look at the conclusions:

Conclusions

  • Complex solution to problem for which simple solutions are widely used and will be improved by C++0x leaving us little need.
  • We have little to no experience with the recommended language features which are to be standardized.
  • Fixing bad software complex system will never work.
  • Recommend minor language changes to improve future GC support - disallow hiding of pointers (xor list trick) as one example.

  • Finally - address the "C++ is bad because it has no GC" argument head-on. C++ doesn't generate garbage and so has no need for GC. Clearly Java, C#, Objective C, etc. generate lots of garbage.

Yes the last sentence is subjective and also a part of the holy wars.
I use C++ because I dislike the idea that someone needs to take out the garbage for me.
The city hall does that and that's enough for me.
If you need GC use another language. Pick the right tool for the right job.