Re: Transfer functionality for shared_ptr
* Dave Steffen:
Oddly enough, this came up over here yesterday...
"Nevin :-] Liber" <nevin@eviloverlord.com> writes:
In article <13gvk7441t5baf0@corp.supernews.com>,
alfps@start.no ("Alf P. Steinbach") wrote:
If you have a shared_ptr, perhaps with a custom deleter of unknown type,
what extra functionality is required to then transfer that shared_ptr's
raw pointer and deleter to some other smart pointer?
[...]
If you want to transfer it to something that is not a shared_ptr, this
seems like a bad idea. After all, shared_ptr is maintaining its own
class invariants (such as the ref count across all instances pointing to
an object). If you let any arbitrary class or function muck with it,
they really aren't invariants anymore.
[...]
I suppose there might be a use for a shared_ptr::release() when
use_count() == 1. Do you have something in mind?
Our use case is this: we have a chunk of code that stores shared
pointers in a queue. We now pop these shared pointers off the queue
in function A and pass them into a 3rd party library that offers a
very C-ish interface; we send in void*'s (argh). Later, in function
B, we get the void*'s back and can call delete on them.
The problem is that when we pop the shared pointers off the queue in
function A, they go out of scope at the end of the function call and
delete what they hold.
If you /control/ the creation of the shared_ptr then you can do it using
the current interface, because you then control the deleter type.
However, I've argued strongly elsewhere for removing the most low-level
"easy" way to do that (namely the possibility of directly changing the
deleter), because it's low level, error prone and dangerous, only easy
like a goto, and that's now or will become Defect Report 730.
A higher level way to do it, still within the current functionality, is
to at the lowest implementation detail level use a deleter functor with
a mutable cancel member,
namespace detail
{
template< typename T >
class CancellableDeleter
{
private:
mutable bool iShouldDelete;
public:
CancellableDeleter(): iShouldDelete( true ) {}
void operator()( T const* p ) const
{ if( iShouldDelete ) { delete p; }
void cancel() const { iShouldDelete = false; }
};
}
and then encapsulate this internal extreme abuse of 'mutable' in a
higher level which abstracts the "release",
template< typename T >
class SharedPtr: public boost::shared_ptr
{
private:
typedef boost::shared_ptr Base;
typedef detail::CancellableDeleter<T> Deleter;
public:
SharedPtr( T* p ): Base( p, Deleter() ) {}
T* release()
{
if( !unique() ) { throw std::logic_error( "not unique!" ); }
T* const result = get();
Deleter const* const d = get_deleter<Deleter>( *this );
if( d == 0 ) { throw std::runtime_error( "nknwn dltr!" ); }
d->cancel();
reset();
return result;
}
};
the point being that this SharedPtr will be compatible with a possible
future const result of get_deleter, and can easily be reimplemented in
terms of a proper transfer_to() operation, if or when... :-)
Disclaimer: off-the-cuff code, not touched by compiler's hands.
Cheers,
- Alf
--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]