GC++, a garbage collector for C++
GC++ is a portable and small garbage collector specifically written for C++.
You do not need to redesign your classes for the basic use of GC++. Just allocate instances with
gcnew and assign the result to a
gc_ptr. An example:
using namespace GCpp;
: f_value (0)
explicit Test (int p_value)
: f_value (p_value)
int value () const
int main ()
gc_ptr<Test> ptr (gcnew (Test) (5));
std::cout << ptr->value () << std::endl;
No problems here, the collector handles such cases correctly.
All tests indicate that it works w/o any problems if the gc_container is used to manage the conatiners. An example:
InnerTest (Test* p_other)
: f_other (p_other)
Test& value () const
typedef vector<gc_ptr<InnerTest> > Vector;
: f_vector (gcnew (Vector))
for (size_t idx (0); idx < 100; ++idx)
f_vector->push_back (gc_ptr<InnerTest> (gcnew (InnerTest) (this)));
Vector& vector_of_inner_test ()
The class Test from the example above may be allocated on the stack or via new or gcnew, the InnerTest instances will be managed correctly in any case.
As of release 0.7, weak pointers are available. See the reference for weak_ptr .
Not supported now and not planned in any future release. I always use STL containers and have not need for arrays.
Thread safety has been improved compared to releases prior 0.6. The creation of the type specific allocators and the allocation of memory (which includes a collection run if needed) are globally protected.
Instances can be allocated via a mix of stack based, new and gcnew allocation without problems.
Destructors are called right before the collector releases an instance back to the memory pool. The order in which destructors are called is unspecified.
The existing tests show a comparable performance.
The collector is in fact a bunch of collectors, one for each type you create at least once in your code with gcnew. If a collector runs out of free memory, it triggers a global mark / sweep cycle and sees if it can reuse memory; the sweep phase is typed, so that the correct destructors get triggered. The collector starts as a conservative one, which means that it assumes that any bit pattern which can be resolved to a valid gc_ptr is in fact one, but during the first collection cycle it continues to check this assumption so it becomes a precise one later. One could say, it is a refining collector.
You need an installed boost to compile the lib ... and a C++ compiler, of course. The build file is a SConstruct, so you will need an installed scons, too. Just unpack the tar and type 'scons'. Giving scons the flag -debug=1 will build a really slow debuggable version of the library and -doc=1 generates this documentation, provided you have doxygen and dot installed.
The SConstruct expects an environment var to point to the boost installation directory. It expects the boost headers at BOOST%\include\boost-1_33_1. If there is enough demand for a precompiled dll, I can provide one generated with VC 2005.
No runtime dependencies other than the runtime deps your compiler adds.
de DOT onlinehome AT usander
Reverse the parts of my email address above. Even better, use the SF trackers and forums.
A very important part of the collector is based on the fixed memory allocator from Andrei Alexandrescu.
GC++ uses the fine boost library. - www.boost.org
Test scripts used during development are Lua scripts. - www.lua.org
Aegis is used to improve the development process. - aegis.sf.net
Scons builds the whole stuff. - www.scons.org
Generated on Thu Dec 27 14:01:59 2007 for GC++ by