From: Philippe A. Bouchard (philippeb_at_[hidden])
Date: 2003-10-06 11:27:36
Philippe A. Bouchard wrote:
[...]
> Would you like me to rename shifted_ptr to gc_ptr since "shifted" was
> used
> as a warning but not needed anymore since make_gc_ptr is going to be
> used & os_collector will be discarded?
I was reading this "tutorial" (thanks to MS):
http://www.csharphelp.com/archives2/archive297.html
C# is using some mark / compact collector. It looks like garbage collectors
are using a lot of memory and the destructors are not even called in C#
(?!?).
What I am going to do:
- I am going the keep collector_traits<>, but move it in some hidden
namespace (detail::shifted_ptr::...) because:
- it is not safe to start playing with (as mentionned by Doug as for
forward declarations);
- I am going to keep os_collector;
- I am going to add a pure gc collector tag (no reference count, pure
garbage collector can take place);
- I need partial specializations if we are not going to use macros.
- The gc_collector I am going to use is the one I was thinking about this
summer:
- mark heap "entities" with another reference count;
- the sizeof(shifted_ptr<T, gc_collector>) is going to be sizeof(void *)
* 2;
- optimized for single thread algorithms (will need help for
multi-threaded version).
- Pure garbage collector is not going to be implemented because is it too
much complex.
So in fact: by using the default alternative the smart pointer is going to
be resonably fast and destructors are going to be properly called even for
cyclic references. This is perfect.
collector_traits<> will look like:
namespace detail
{
namespace shifted_ptr
{
struct gc_collector {}; // pure garbage collector, no reference count
struct rc_collector {}; // regular reference count
struct os_collector {}; // still ownership
struct rgc_collector {}; // referenced garbage collector
template <typename T>
struct collector_traits
{
typedef rgc_collector type; // default one
};
...
}
}
So in fact the referenced garbage collector is going to be the default one
and destructors will not be postponed. I am going to keep the ownership
alternative because it fits perfectly for containers or other internal
usages IMO.
Philippe