Boost logo

Boost :

From: Darin Adler (darin_at_[hidden])
Date: 2002-02-12 14:45:27

On 2/12/02 11:31 AM, "Peter Dimov" <pdimov_at_[hidden]> wrote:

> 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( {}
> It's completely exception neutral; the exception is thrown by the underlying
> shared_count construction.

Yes, I understand that this behavior comes naturally from the
implementation. Believe it or not, I actually spotted that when reviewing
the code.

I think this is one of the main places where the difference in our opinions
arises. I am not much swayed by what's most natural to implement and more
swayed by what seems most natural to use. I understand that given the
relationship between shared_ptr, weak_count, and shared_count, it's hard to
make this shared_ptr constructor result in a 0 when the weak pointer is 0.
But I think this is making the interface subordinate to the implementation.

On possibility would be to make this shared_ptr constructor be private, make
make_strong() be a friend, and eliminate weak_ptr::get(). Of course, this
might run afoul of some existing compilers or something like that.

I think I've made my opinion and arguments as clear as I can, and I don't
think I have more to add. Let me know if I can help further.

    -- Darin

Boost list run by bdawes at, gregod at, cpdaniel at, john at