Boost C++ Libraries: Ticket #5381: get_deleter(ptr) needs D to be exactly known

Steven Watanabe — Wed, 06 Apr 2011 21:32:50 GMT

get_deleter<Base_of_D>(ptr) returns 0.

This makes efficient polymorphous COW pointer implementations internally based on shared_pointer inefficient, because it is not possible to have reference count (deleter) and pointee allocated in one memory block, as is done in boost:::make_shared. Note, COW pointer need access to the deleter for the clone function at a time later than the constructor.

I don't understand. If you want to make something like make_shared, you should only need to access the deleter when you're constructing the object. At this point, you need to know the exact type of the deleter anyway. Actually, though, I don't see what you want to do that can't be handled by just using make_shared.

christian.kotz@… — Thu, 07 Apr 2011 18:25:42 GMT

For a copy on write pointer it is not sufficient to use the actual type in the constructor only, where it is known, a la make_shared. On dereference (not construction time) it may be necessary to lazily clone (create a copy) of the pointee. In this case splicing must be avoided, so even if we have a shared_ptr<Base> which has been constructed from a make_shared<Derived> invokation the actual pointee carrier must be cloned (Derived not Base!).

here some code fragments, which sketch the "deleter"

class Carrier_base {

... most omitted private:

virtual Carrier_base *clone() = 0;

};

template <typename T, typename A = ::std::allocator<T> > class Carrier :

private A::template rebind<T>::other

{ ... most ommitted

typedef typename A::template rebind<T>::other allocator_type;

template <typename Other_A, typename... Args> static Carrier<T,A> * create(Other_A allocator, Args... args);

T * address() const;

private:

template <typename Other_A, typename... Args> explicit Carrier(Other_A allocator, Args... args);

Carrier<T,A> * clone() const{ override

Carrier<T,A> * result = allocate(1,0); try {

new (allocator_type(*this)) Carrier<T,A>(*this);

} catch(...) {

deallocate(result); throw;

} return result;

}

};

If I only allow construction in a make_shared like fashion, I know on clone time that only a class derived from Carrier_base can be the deleter. This is sufficient to invoke cloning. The actual Carrier<X> need not and cannot be in general be known. Note COW pointer is not a ::boost::shared_ptr but privatrely inherits from one or has a private member.

anonymous — Thu, 07 Apr 2011 18:42:47 GMT

A solution could be to expose some internals to derived classes of ::boost::shared_ptr via protected, not private access control. This will on one side not endanger usage of shared_ptr, while giving implementations based on shared_ptr access (implementation is inherited via non public, e.g. private inheritance).

christian.kotz@… — Thu, 07 Apr 2011 18:50:25 GMT

remark: Carrier<T,A> has the same function for the COW_ptr as boost::details::sp_ms_deleter in boost::make_shared

status changed; resolution set

Peter Dimov — Fri, 13 Dec 2013 22:35:19 GMT

status new → closed
resolution → wontfix

Given its age, this ticket is probably no longer relevant. Still, there is now an undocumented accessor, void * _internal_get_untyped_deleter() const, which can be used. It's not very likely to be provided as part of the public interface though.