Re: [boost] boost::scoped_array::release?

From: Howard Hinnant (howard.hinnant_at_[hidden])
Date: 2006-03-12 16:27:09

On Mar 12, 2006, at 5:22 AM, Peter Dimov wrote:

>> How do you say:  I don't care about the copyright?  Copy it, trash
>> it, do include my name or don't, I don't care.  It's only here for
>> your amusement.  I'm attempting to post anonymously.
>
> "I, Howard Hinnant, hereby place this code in the public domain"

Thanks Peter, done.

On Mar 12, 2006, at 4:54 AM, Ion Gaztañaga wrote:
>> Btw, I neglected to include Ion's suggestion:
>>
>>> If we can define the pointer type via deleter::pointer or similar
>>> (with default T*) that would be even better.
>>>
>>
>> which I think is a good one.  Update on the way...
>
> Can we add that also for unique_ptr Reference Implementation?
>
> http://home.twcny.rr.com/hinnant/cpp_extensions/unique_ptr.html

Done.  But I did it differently then my first attempt yesterday.   
Yesterday I had:

template <class T, class D = ...>
class unique_ptr
{
public:
     ... typedef typename D::pointer;
};

But this disallows handy deleters such as:

struct my_deleter
{
     // no way to define pointer typedef!

     template <class T>
     void operator()(T* p) {...}
};

which I found distressing.

So now both the reference and emulation implementations will use  
D::pointer only if it exists in D, otherwise T* is used.  This is not  
only more flexible, but also more convenient.  You can forget about  
defining the pointer typedef in your deleter unless you really care  
about it.

If you get the chance Ion, see how this emulated unique_ptr stands up  
to your shared memory torture test (and thanks). :-)

> With so many smart pointers, I'm certainly confused. What's the
> difference between unique_ptr:
>
> http://home.twcny.rr.com/hinnant/cpp_extensions/unique_ptr.html
>
> and move_ptr:
>
> http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2002/ 
> n1377.htm#move_ptr%20Example

unique_ptr is essentially a renaming of move_ptr (in addition to  
minor refinements such as the deleter policy and array handling).  A  
couple of years ago I became disenchanted with the name move_ptr  
because several smart pointers could have a move constructor that  
differed from its copy constructor (e.g. clone_ptr).  So I searched  
for a new name which stressed the pointer's ownership behavior  
instead of simply showcasing move semantics.

> Do we need scoped_ptr in future C++ standard if unique_ptr has all
> needed operations? Or it's too dangerous for a scoped resource pattern
> because of the release() operation?

I'll let others address (and possibly propose) that one.  I've  
personally never really used scoped_ptr and so would be the wrong  
champion for it.

-Howard