[boost] Re: SmartPtr (Loki) - auto_ptr/move c'tor issue

From: David B. Held (dheld_at_[hidden])
Date: 2003-02-02 03:09:01

"David Abrahams" <dave_at_[hidden]> wrote in message
news:ulm11ouyy.fsf_at_boost-consulting.com...
> [...]
> If eating the cake means "not having to support unmanaged adoption",
> I don't think so ;-)

Well, I meant support both, of course.  How hard would it be to create
the generic managed c'tor?

> > [...]
> > Now, the first that happens is that storage(p) attempts to take
> > ownership of p.
>
> p is an auto_ptr<U>&, so how is that ever going to happen?

Well, this was sloppy wording.  I meant that storage will try to
take ownership of p's resource.

> > For default storage, this is a no-throw operation.  Let's say we're
> > moving p into a counted pointer.  Now ownership has to allocate
> > a count, and might throw in the process.  If it does, we either have
> > to clean up p, or we have to stuff the toothpaste back into the
> > tube.
>
> Both highly imprecise notions; I don't know what either means for sure
> in this context.

Substitute 'p' for 'p's resource', and maybe it will make more sense.

> > I see that shared_ptr solves this by violating RAII.
>
> I don't know what this means either.  RAII is not something you can
> "violate".  It's a technique or idiom.

By "violate RAII", I mean, use default construction with a try-catch
block rather than the initializer list.  The "RAII philosophy" that you've
been preaching for the last week is that you almost never need a catch
block if you use RAII properly.

Dave