Boost logo

Boost :

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.

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?


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