Re: [boost] scoped_ptr rationale

From: Howard Hinnant (hinnant_at_[hidden])
Date: 2002-09-21 19:15:45

On Saturday, September 21, 2002, at 07:16  PM, Peter Dimov wrote:

> Yes, this is the "official" scoped_ptr rationale, but note that foo can
> often be rewritten as
>
> T* foo(T* x, /* ... */)
> {
>      T t;
>      //
>      // big, long, hairy, function
>      // ...
> }
>
> and that big, long, hairy functions are problematic either way.

Thanks for the kick in the pants for me to actually go RTFM! :-)

scoped_ptr's docs actually seem to say what I'm trying to say:

> The scoped_ptr template is a simple solution for simple needs. It 
> supplies a basic "resource acquisition is initialization" facility, 
> without shared-ownership or transfer-of-ownership semantics. Both its 
> name and enforcement of semantics (by being noncopyable) signal its 
> intent to retain ownership solely within the current scope.

The swap function opens a window of opportunity to transfer ownership 
out of the current scope (motivation understandable given the lack of 
move semantics support in the current language).  If move_ptr flies, I 
think it would be a Good Thing for scoped_ptr to go back to its roots 
(toss the swap, don't add a release).  Once you put something in to a 
scoped_ptr, it is not going to get transferred out.

As for applications, I'm having a hard time believing that a scoped_ptr 
that only served the "current scope" intention would be useless.  I 
agree that it might not be as widely used as a smart pointer capable of 
resource transfer, but I'm not convinced that it would be useless.  
Maybe:

void foo(int n)
{
      scoped_array<char> p(new char[n])
      ostrstream os(p.get(), n);
      ...
}

This is certainly less error prone than:

void foo(int n)
{
      move_array<char> p(new char[n])
      ostrstream os(p.get(), n);
      ...
      // accidently transfer p out before os destructs?
      ...
}

-Howard