id,summary,reporter,owner,description,type,status,milestone,component,version,severity,resolution,keywords,cc
10798,boost::movelib::unique_ptr resolves typedef pointer with the deletor's,Matteo Settenvini <matteo.settenvini@…>,Ion Gaztañaga,"Hello,

as part of a project which entails adding some sort of virtuality in shared memory, we are using {{{boost::interprocess::unique_ptr}}} extensively; this, starting from 1.57.0, maps directly to {{{boost::movelib::unique_ptr}}}.

I am providing a short example that exposes the problem (see attachment).

We use a generic deleter which is non-virtual and takes a pointer to a common base class for destruction+deallocation with a custom allocator. The deleter must have a ""{{{typedef ... pointer}}}"" member, since it needs to work also with {{{boost::interprocess::shared_ptr}}}.

However, the current implementation of unique_ptr has also a member ""{{{typedef pointer}}}"" which indirectly resolves to Deleter::pointer. That means that {{{unique_ptr<Derived>::pointer}}} ≡ {{{Deleter::pointer}}} ≡ {{{Base}}}.

Since e.g. {{{unique_ptr::operator->()}}} or {{{unique_ptr::get()}}} have a return type of type ""{{{pointer}}}"", each use of them effectively returns a pointer to the base class, which then needs manual static or dynamic casting.

I am providing also the patch we are currently using to work around the issue. Of course, this is just a quick hack and not suitable for Boost, but it helps to pinpoint the problem.",Bugs,closed,To Be Determined,move,Boost 1.57.0,Problem,wontfix,,