Re: Implementing a smart pointer which works with incomplete types
Juha Nieminen wrote:
template<typename T>
class GenericPtr
{
private:
typedef void(*DeleteFunctionType)(T* p);
DeleteFunctionType deleteFunction;
T* ptr;
static void doDelete(T* p) { delete p; }
public:
GenericPtr(T* p): ptr(p), deleteFunction(doDelete) {}
~GenericPtr() { deleteFunction(ptr); }
// other functions omitted
};
Since nobody seems to be able to give a *clear* answer to the
question, let's see if I have figure this out correctly:
Template functions seem to have this funny property that they are not
"instantiated" (ie. an actual physical function is not created) until
they are referred to, in one way or another. This seems to be so even if
the function in question is inside a template class which *is* being
instantiated.
For example, even though GenericPtr is being referred to like:
class SomeClass;
class SomeOtherClass
{
GenericPtr<SomeClass> ptr;
public:
SomeOtherClass();
};
the 'doDelete()' function inside it is *not* being instantiated because
nothing is referring to it yet. There may be all kinds of code inside
that function which assumes some content in the incomplete type, like
for example:
static void doDelete(T* p) { p->printMsg("Hello"); delete p; }
yet this will not cause any error, even though at this point T refers to
an incomplete type, because 'doDelete()' is not being instantiated yet.
The destructor of 'GenericPtr' seems to have a special role, though.
If 'SomeOtherClass' has no destructor, then the destructor of
'GenericPtr' is being instantiated immediately. Thus this destructor
cannot refer to the incomplete type in any way. The destructor in
question is only referring to the function pointer, which is being
instantiated immediately, but that's not a problem because it's just a
pointer and has no code in itself.
If 'SomeOtherClass' *does* have a destructor, however, then the
instantiation of the destructor of 'GenericPtr' seems to be delayed,
transferred to the instantiation of the destructor of 'SomeOtherClass'.
Thus in this case the destructor of 'GenericPtr' could refer to anything
inside T without problems.
I haven't actually tested, but I would guess that the constructor has
similar behavior: Since 'SomeOtherClass' has a constructor, the
constructor instantiation of 'GenericPtr' is being transferred to the
constructor implementation of 'SomeOtherClass' instead of being
instantiated immediately.
When the constructor of 'SomeOtherClass' is implemented, that
instantiates the constructor of 'GenericPtr', which in turn instantiates
'doDelete()' because the constructor refers to it. If in this context
'SomeClass' has been fully declared, no problems happen. A pointer to
this 'doDelete()' instance is stored, and everything works fine.
Does this "delayed instantiation" of functions work also with regular
member functions, or does it only work for static class functions?