Re: Design summary: smart pointers in allocators

["Phil Bouchard" <philippe at fornux dot com>]

"Phil Bouchard" <philippe@fornux.com> wrote in message 
g932vp$fg2$1@ger.gmane.org">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