The purpose of the class gc_ptr<T> is to know where the global/stack pointers are. Member pointers do not need a special class, since each heap object is fully scanned for pointers to other objects. Here is an example of my approach: class MyClass : public gc_object { public: MyClass *other; }; gc_ptr<MyClass> obj1 = new MyClass; obj1->other = new MyClass; The above approach assumes that GC objects are heap-allocated. There are alternatives though, if one wishes to have GC objects either in heap or stack: ------------------------------------------------------- Alternative 1 - using gc_ptr<T> for global, stack and member pointers. It is possible to use the gc_ptr class for global, stack and member pointers. The class would have to check if it belongs in the last-known created object by checking its address against the address of the last created object. If the pointer falls within the memory area of the last created object, then it is a member pointer, otherwise it is a global/stack pointer. Example code: template < class T > class gc_ptr { public: gc_ptr() { if this not within last created object then { pointer stack->push(this); } } }; Advantages of this approach: 1) only one special pointer class to use. Disadvantages of this approach: 1) non-precise garbage collection, since the system does not know which pointers exist 2) slower sweep, as memory blocks need to be scanned fully 3) slower than alternative #2, since the check for if the pointer is a global/stack or member pointer is repeated for root pointers as well. ------------------------------------------------------- Alternative 2 - using two different pointer classes. A better alternative (for performance reasons) is to use two different pointer classes, one for member pointers and one for root pointers. Example: template < class T > class member_ptr { public: member_ptr() { if this not within last created object then { pointer stack->push(this); } else last created object->register_member_ptr(this); } }; template < class T > class root_ptr { public: root_ptr() { pointer stack->push(this); } ~root_ptr() { pointer stack->pop(this); } }; Then usage will be: class MyClass : public gc_object { public: member_ptr<MyClass> other; }; root_ptr<MyClass> obj1 = new MyClass; obj1->other = new MyClass; advantages of this alternative: 1) precise garbage collection, since only garbage-collected pointers are scanned 2) faster sweep phase, since only garbage-collected pointers are scanned disadvantages of this alternative: 1) a performance hit, since member pointers need to be initialized as well. 2) it needs more memory, since each allocated block needs space for storing member pointer offsets. "Dave Harris" <brangdon@cix.compulink.co.uk> wrote in message news:memo.278799@cix.compulink.co.uk...
In-Reply-To: <dpsep6$t6q$1@sea.gmane.org> axilmar@b-online.gr (Achilleas Margaritis) wrote (abridged):
the following proposal is about a small library for multithreaded garbage collection using only boost threads.
Am I right in thinking your approach does not allow pointers to objects to be embedded into other objects? They have to be on the stack?
If so, I imagine that would be a fairly severe limitation. It prevents you from having circular chains of pointers, support for which is usually one of the reasons for adopting GC.
-- Dave Harris, Nottingham, UK.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost