|
Boost : |
From: Peter Dimov (pdimov_at_[hidden])
Date: 2002-02-12 14:31:45
From: "Darin Adler" <darin_at_[hidden]>
> I think that an interface that doesn't use exceptions at all would be just
> great. There's nothing here that's crying out for an exception.
[...]
> It's true that constructors customarily throw exceptions when they can't
> construct an object; because they must!
Exactly.
> And if a shared_ptr couldn't hold a
> 0, then it would be a great choice for it to throw an exception if you
> attempted to construct it from a weak_ptr that held a 0. But it seems
nearly
> gratuitous to throw an exception in passing just because we're dealing
with
> a 0 pointer when both types handle the 0 pointer just fine.
The "exceptionful" interface falls out from the natural code flow. I haven't
gone out of my way just to implement it. Here's how things work:
shared_count has a constructor that takes a weak_count. It tries to
increment the use_count() of the count object. When the use_count is zero,
this operation throws an exception, since incrementing the use_count from 0
to 1 doesn't have a meaning and will result in a corrupted shared_count that
will fail in its destructor with undefined behavior.
shared_ptr's constructor looks like this:
explicit shared_ptr::shared_ptr(weak_ptr const & r): px(r.px), pn(r.pn) {}
It's completely exception neutral; the exception is thrown by the underlying
shared_count construction.
> If it was entirely up to me, I'd probably have the shared_ptr constructor
> allow implicit type conversion,
This will create ambiguities since a shared_ptr implicitly converts to a
weak_ptr; implicit conversions are better left unidirectional.
-- Peter Dimov Multi Media Ltd.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk