How to get working with covariant shared_ptr trick?

One problem with using shared_ptr's in general is that covariant return types don't work for them. I have a class I'd like to have a Clone() member function. When B inherits from A, then A* and B* are covariant but shared_ptr<A> and shared_ptr<B> are not. There's a trick for getting around this documented here:

http://lists.boost.org/boost-users/2003/02/2996.php

His syntax is slightly wrong (you pass the raw cast pointer to the shared_ptr's constructor rather than assigning) but you get the basic idea. You have a protected virtual function that uses raw covariant pointers and a public function that uses it and wraps the result in a shared_ptr. The problem I'm having is that with new_ptr the wrapper function can't make a shared_ptr from the virtual function's raw pointer anymore: the compiler complains ~MyClass() is private (as new_ptr's usage suggests it should be).

Can anyone think of a way to make new_ptr workable somehow with covariant returns? Other than that I love it :)

dataangel said

The problem I'm having is that with new_ptr the wrapper function can't make a shared_ptr from the virtual function's raw pointer anymore: the compiler complains ~MyClass() is private (as new_ptr's usage suggests it should be).

The private constructors and destructor is there to ensure that objects of that type cannot be constructed on the stack. If that isn't relevant then you wouldn't do that.

As for the compiler's complaint, is there a reason you don't just extend friendship to the wrapper function?

Kirit said

dataangel said

The problem I'm having is that with new_ptr the wrapper function can't make a shared_ptr from the virtual function's raw pointer anymore: the compiler complains ~MyClass() is private (as new_ptr's usage suggests it should be).

The private constructors and destructor is there to ensure that objects of that type cannot be constructed on the stack. If that isn't relevant then you wouldn't do that.

As for the compiler's complaint, is there a reason you don't just extend friendship to the wrapper function?

Sorry I wasn't clear — the complaint from the compiler isn't that the wrapper function doesn't have permission. The wrapper function is already part of the class so AFAICT friendship wouldn't make a difference. The problem is that boost::shared_ptr's internals don't have access to the destructor. Looking at the new_ptr code, it looks like your trick is to pass the shared_ptr constructor an alternative deallocator, so it doesn't have this problem. But when the wrapper function wants to make a shared_ptr out of the raw pointer it already has, it can't use new_ptr (because the object has already been allocated), nor does it have access to new_ptr's deallocator. I guess I could reproduce the trick with my class having it's own new_ptr-like deallocate function, but that's getting awfully hacky…