Design summary: smart pointers in allocators
Phil Bouchard
philippe@fornux.com
Thu Aug 28 13:20:00 GMT 2008
"Phil Bouchard" <philippe@fornux.com> wrote in message
news:g932vp$fg2$1@ger.gmane.org...
[...]
> But I was considering yet another approach which would have to be well
> tested in terms of usability because it may involve run-time issues. The
> idea would be to add an implicit convertion function to type "void *" to
> the
> smart pointer class. But this operator woudl require giving away its
> ownership of the pointer and returning 0 (nullptr) if the reference count
> isn't yet down to zero:
>
> template <typename T>
> class smart_ptr
> {
> ...
> operator bool () ...
> operator const void * ()
> {
> return -- _M_count ? 0 : _M_p;
> }
> };
[...]
As it turns out I think a release() member function should be added to the
smart pointer which will give away ownership of the object (pseudo-code):
template <typename T>
class smart_ptr
{
...
smart_ptr(element_type *);
value_type * get();
element_type * release()
{
element_type * __p = pointer_ref();
pointer_ref() = 0;
if (-- counter_ref())
return 0;
else
return __p;
}
};
It follows the same idea of its predecessor auto_ptr<> but will return a
null pointer if the object is still shared hence not ready to be deleted.
This way the allocator will be much easier to support either by calling this
function before deallocate(), inside it or by using a specialized wrapper
class to handle it:
template <typename T>
class allocator
{
...
typedef smart_ptr<T> pointer;
void deallocate(pointer & __p)
{
delete p.release();
}
};
-Phil
More information about the Libstdc++
mailing list