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

From: David Abrahams (dave_at_[hidden])
Date: 2003-02-02 06:03:32

"David B. Held" <dheld_at_[hidden]> writes:

> "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?

Search me!

>> > 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.

Not really.

   - by "clean up" you mean "delete?"
   - by "stuff stuff the toothpaste back..." you mean "move p back into
     the source pointer?"

>> > 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.

I don't think I ever said that.  It's usually true, and it's good that
you noticed, though.

-- 
                       David Abrahams
   dave_at_[hidden] * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution