"David Abrahams" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> [...]
> BTW, this is also not the "strong guarantee" (I dunno, maybe people
> mean something else by "strongly exception safe" -- is there a
> definition somewhere?)

Does it even make sense to say that a c'tor provides the strong
guarantee?  It seems that the strong guarantee is more appropriate
for describing operations on fully constructed objects.

> [...]
> The problem is that it's not very usable when the resource is passed
> via some unmanaged mechanism like a raw pointer, because then
> you need to protect it with something like an auto_ptr, and in the
> case of a "do everything smart pointer" that's really somewhat silly
> isnt it?

So if I understand you correctly, you're saying SmartPtr *should*
take ownership regardless of whether a policy c'tor throws, and thus,
when a policy c'tor throws, the SmartPtr should do the right thing and
free the resource?

> [...]
> You don't need that; you can just use a smart pointer member
> <0.5 wink>

Sorry, I don't follow.  Do you mean that SmartPtr<> should really
be a wrapper for the implementation, and it is the implementation
that actually calls the policy c'tors?  Even then, I don't see how you
can get away from having to catch an exception from an initializer
list.

> > [...]
> > Given how often people write auto_ptr<> without writing
> > auto_ptr<>, I'd say yes. ;>
>
> Not a challenge, but can you give an example?  I've never seen it
> and I have trouble imagining why someone would do it.

Well, what I meant was that people don't necessarily write a smart
pointer with the full auto_ptr semantics.  More often, it turns out to
be something like scoped_ptr.  But the people I know who do that
tend to not know about the Boost pointers in the first place, and
think they are inventing something cool because they understood
enough about auto_ptr<> to make their own version with feature
X (though usually not with the full move semantics).

Dave



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Reply via email to