|
Boost : |
From: David B. Held (dheld_at_[hidden])
Date: 2003-01-29 00:19:15
"David Abrahams" <dave_at_[hidden]> wrote in message
news:ulm15gj97.fsf_at_boost-consulting.com...
> [...]
> 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk