Boost logo

Boost Users :

Subject: Re: [Boost-users] scoped_ptr::release (again)
From: Christopher Jefferson (chris_at_[hidden])
Date: 2009-02-24 14:37:16


On 24 Feb 2009, at 19:26, Matthieu Brucher wrote:

> 2009/2/24 Steven Watanabe <watanabesj_at_[hidden]>:
>> AMDG
>>
>> Nat Goodspeed wrote:
>>>
>>> Christopher Jefferson wrote:
>>>
>>>> I'd vote for keeping scoped_ptr as simple as possible, even
>>>> removing that
>>>> swap, and directing people who want more power to unique_ptr.
>>>
>>> I'd like to keep swap(). If the coder wants to disable it,
>>> wouldn't 'const
>>> scoped_ptr' suffice?
>>>
>>> If I have a class that supports assignment, and my class uses
>>> scoped_ptr
>>> to manage some resource, Herb Sutter's exception-safe assignment
>>> operator
>>> still applies:
>>>
>>> 1. Construct a new stack scoped_ptr with the incoming resource. An
>>> exception here leaves *this unmolested.
>>> 2. Swap the member scoped_ptr with the new scoped_ptr. (swap() is
>>> guaranteed not to throw.)
>>> 3. Leaving the assignment-operator method body destroys the temp
>>> stack
>>> scoped_ptr, releasing the member scoped_ptr's previous data.
>>
>> The question is not whether swap is useful, but whether it should
>> be part of scoped_ptr rather than another smart pointer.
>>
>> In Christ,
>> Steven Watanabe
>
> Which other smart pointer? Scoped_* is really simple and the optimized
> code is the same as a naked pointer, which is what some people need.
> For me, scoped_* is exactly what I need:
> - RAII
> - tantamount to a simple pointer
> - possible to swap pointers

unique_ptr offers exactly that set too, along with:

  - possible to move pointers.
  - ability to use custom deleter if you want (I don't know if
scoped_ptr offers that.. it is zero overhead if you don't use it).

The only reasons to use scoped_ptr over unique_ptr, once it is
present, will be if you don't want to be able to move things around.
Probably the nicest feature of unique_ptr of scoped_ptr is that it can
be returned from functions.

Chris


Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net