Boost logo

Boost :

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?

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

template <class T, class D = ...>
class unique_ptr
     ... 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:
> and move_ptr:
> 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.


Boost list run by bdawes at, gregod at, cpdaniel at, john at