Re: [gtkmm] using RefPtr out of Gtkmm

[Chris Vine <chris cvine freeserve co uk>]

On Wednesday 11 February 2004 22:32, Paul Elliott wrote:

[snip]

> On the other hand, there is a logic to intrusive reference counting
> where there is inheritance. Suppose Derived is derived from Base,
> and EvenMoreDerived is derived from Derived. Suppose my_instance
> is a instance of EvenMoreDerived. Different modules "think"
> of my_instance in deferent ways. Module A deals with my_instance
> as a Base and wants to keep a smart pointer to base of my_instance.
> Module C deals with my_instance as a Derived and wants to keep
> a smart pointer to my_instance as a Derived. Module C deals with
> my_instance as an EvenMoreDerived ect.
>
> How would you do that with unintrusive pointers? smart_ptr<Base>,
> smart_ptr<Derived>, smart_ptr<EvenMoreDerived> how do they
> all use a common reference count?
>
> With intrusive reference counts, the refcounts can be hidden
> in the Object class that all these other classes have to be dervied from.
>
> With unintrusive reference counts the templade smart_ptr<EvenMoreDerived>
> does not even know that Base and Derived exist, so how can it
> use the same reference counts as these?

By using template member functions in the smart pointer, and using 
smart_ptr<Base> to reference the class heirarchy.  Any competently written 
constructors for a smart pointer will include a templated constructor[1], so 
allowing a base smart pointer to be initialised by a derived object by 
implicit conversion (and also a templated operator=() function for the same 
reason).  If the base class has a virtual destructor (as it should), then all 
will work correctly.

Chris.

[1] Thus the constructors for std::auto_ptr include:

template <class T> class auto_ptr {
public:
 ...
 ...
// this constructor not templated - strict type matching required
auto_ptr(auto_ptr&);
// and this constructor templated allowing implicit conversions
template <class U> auto_ptr(auto_ptr<U>&);
 ...
};