How is the precision achieved without compiler support?

The class 'ptr' (used for global and stack pointers) pushes itself in the current collector's stack on construction and removes itself from that stack on destruction. Example: ptr<Foo> ptr1 = new Foo; The class 'member_ptr' is registered to the owner object in the owner object's constructor. Example: class Foo : public object { member_ptr<Foo> next; Foo() : next(this) { } }; The above is one of the available strategies. The library allows custom mark strategies to be implemented so as that member_ptrs need not be used. For example: class node { public: node *prev; node *next; void *operator new(size_t size, temp_ptr &tmp = temp_ptr) { return get_garbage_collector().malloc(size, 0, &mark, 0, tmp); } static void mark(void *p) { node *n = (node *)p; get_garbage_collector().mark(node->prev); get_garbage_collector().mark(node->next); } };

Why are array specifically mentioned? Does this mean they have to be declared as garbage collected?

Yes. Arrays are declared like this: ptr<array<Foo> > array1 = new array<Foo>[10]; The reason is that I needed to specify 'operator new' for arrays.

I'll probably have some as soon as I can read and understand the above link. Meanwhile, you might want to compare it with the precise collector in the policy_ptr library in boost sandbox.

Thanks a lot. I will check it out. Achilleas

[snip] If Foo is on the stack, is Foo::next pushed on current collector's stack? If std::vector<Foo> is on the stack, are all it's contained Foo::next's pushed on the current collector's stack?

I was going to reply with a 'no' (i.e. if Foo is on the stack then Foo::next is not pushed in the current collector's stack), when I realized the many problems that will be created by that. So I went and redesigned the library, and now the following are possible: 1) declaring garbage-collected objects either on the heap or on the stack. 2) declaring garbage-collected arrays either on the heap or on the stack. 3) allocating garbage-collected arrays of objects (not pointers of objects, arrays of objects). 4) having garbage-collected pointers point to members of garbage-collected objects that are not pointers. In other words, the following is possible: class bar : public object { }; class foo : public object { ptr<foo> next; bar bar1; }; ptr<foo> foo1 = new foo; ptr<foo> foo2 = new foo[10]; ptr<foo> foo3[10]; foo3[5] = foo2 + 3; ptr<ptr<foo> > ptr1 = new ptr<foo>; *ptr1 = foo3[5]; foo1->next = new foo[10]; ptr1 = new ptr<foo>[10]; ptr<bar> bar1 = &foo1->bar1; Now coding is similar to normal c++ coding but with these exceptions: a) the programmer needs to use 'ptr' or 'weak_ptr' class either as a member or a stack pointer. b) garbage collected objects should inherit from 'object'. The collector provides per memory block policies for managing finalization and marking. I have posted the new implementation in the vault, under memory; the library is complete except for weak_ptr (but the infrastructure is completed, and adding weak_ptr is easy). As always, discussion and analysis are welcomed. Achilleas

Achilleas Margaritis wrote:

It seems there is not interest for such a library after all. Anyway, I placed the final beta version in the vault under memory. The only library it uses is pthreads, so it should be portable (I have tested it on msvc++ 7 so far).

Your problem in gaining interest is that your documentation does not explain the use of your library. This is a common mistake of many programmers, who put out implementations and assume that anyone interested must be willing to spend hours or days figuring out, somehow, what is there and how it is to be used. Inevitably, no matter how original or creative that implementation may be, it will be unused by the vast majority of people who, given adequate documentation, might be interested in it. Take a look at the Boost documentation for its libraries to see what should be done to explain the use of yours. Then, if you update your documentation and explain well what your library does and how the end user should use it in its main use cases, I believe you will garner some interest by potential users.