Boost C++ Libraries: Ticket #10798: boost::movelib::unique_ptr resolves typedef pointer with the deletor's

attachment set

Mon, 17 Nov 2014 12:41:21 GMT

attachment → boost-movelib-unique_ptr-deleter-issue.cc

Small example showing the compilation error

attachment set

Mon, 17 Nov 2014 12:41:48 GMT

attachment → 003-move-unique_ptr-pointer-type.patch

Temporary workaround patch

Ion Gaztañaga — Mon, 24 Nov 2014 21:30:14 GMT

boost::interprocess:unique_ptr was never designed for this use case, at least, not on purpose. It was designed to be nearly-standard compatible and compatible with managed_unique_ptr, which defines a deleter with a pointer typedef, defining a smart pointer to the element_type. Couldn't a new unique_ptrdeleter that derives from your deleter and defines pointer to be a pointer to T, solve the issue?

Tue, 25 Nov 2014 08:52:27 GMT

Unfortunately not, since the deleter I wrote uses a field of the base class to determine the runtime type of the object, and resolves a call to the right destructor (plus, deallocates memory with the right custom allocator). This is needed since we have no virtuality in objects of classes that need to be stored in shared memory.

In other words, I need to use just a deleter for the whole hierarchy of classes, and thus its pointer member needs to be the base type. We're rolling out our handmade version of virtuality, with virtual tables and all that goes with them.

What I find counter-intuitive from a design standpoint, is that:

be it that we have classes Derived < Base.
given a Deleter with a member "pointer" as a typedef to Base.
defining a unique_ptr<Derived, Deleter> and invoking ::get() results in a pointer to Base being returned.

What is the technical reason of having the pointer typedef of the unique_ptr using the pointer member of the deleter, instead than rebinding it to allow upcasts?

status changed; resolution set

Ion Gaztañaga — Mon, 15 Dec 2014 16:30:53 GMT

status new → closed
resolution → wontfix

The reason is that the standard mandates that:

en.cppreference.com/w/cpp/memory/unique_ptr

pointer 	std::remove_reference<Deleter>::type::pointer if that type exists, otherwise T*

boost::movelib::unique_ptr is an implementation of the standard unique_ptr for boost. The Interprocess implementation had definitely a bug because it was also trying to implement the standard.

I think you can workaround it with a new deleter that inherits from your polymorphic deleter that just forwards it. Something like (simplified example):

template<class Derived>
struct new_deleter
  : public old_deleter
{
  typedef my_pointer<Derived> pointer;
  void operator()(pointer p)
  {  old_deleter::operator()(p);  } //Call polymorphic deleter
};

Tue, 16 Dec 2014 11:02:22 GMT

Thanks, but then it wouldn't work with upcasting (and downcasting too). I would end up with a shared_ptr<Derived, new_deleter<Derived>> which is not automatically convertible to a shared_ptr<Base, new_deleter<Base>>.