Re: Smart pointers and inclomplete types
Kai-Uwe Bux wrote:
Note that intrusive_ptr is not boost::intrusive_ptr, because that won't
compile on my platform. I wrote something similar (see below). However,
I am unsure whether boost::intrusive_ptr would have defined behavior in
this case, and if it does so, why?
It would not.
However, std::tr1::shared_ptr (and boost::shared_ptr) probably would.
Any Ideas?
The cyclic dependency is really needed from the designs point of view.
You might want to have a look at the implementation of boost::shared_ptr.
The key idea is to store a deleter within the shared_ptr and initialize
that one upon construction (with an appropriate default). This way, the
problem can be postponed until shared_ptr objects need to be initialized.
Only at that point, the type has to be complete.
Hmm, I intensionally preferred intrusive pointers because of their small
memory footprint. Furthermore it is a major design change, because the
current interfaces rely on the fact that passing T* instead of
int_ptr<T> as function argument is sufficient even if int_ptr<T>
instances may be assigned from the parameter in the function body.
Maybe I can apply something like that what you have mentioned to the
scoped_ptr and forward declare the Iterator class.
/* Abstract non-template base class of int_ptr */
class int_ptr_base
{protected:
Iref_Count* Ptr;
public:
// Store a new object under reference count control
// or initialize a NULL pointer.
int_ptr_base(Iref_Count* ptr);
// Copy constructor
int_ptr_base(const int_ptr_base& r);
// Destructor core
Iref_Count* unassign();
// some more functions...
};
template <class T>
class int_ptr : protected int_ptr_base
{public:
// Store a new object under reference count control
// or initialize a NULL pointer.
int_ptr(T* ptr = NULL) : int_ptr_base(ptr) {}
// Destructor, frees the stored object if this is the last reference.
~int_ptr() { delete (T*)unassign(); }
The line above is either wrong or too smart: nothing (except the comment)
indicates that the reference has to be last.
unassign returns NULL unless it removes the last reference. Well, not
documented that nicely. The whole trick is to do anything but the
absolutely needed part in a non-template base. This keeps the binary
compact.
Marcel