Re: [boost] more comments on new weak_ptr

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

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

> Perhaps. Do you have a better interface in mind?

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. The notion
of weak_ptr and the notion of an explicit check to see if the original
object went away seem to go hand in hand.

My only worry is that there are a number of ways to accidentally use
weak_ptr in an unsafe manner. I'd almost prefer that weak_ptr itself not
offer a way to check for 0 (the bool conversion and operator !), because
providing those operations makes it more likely that programmers will write
code that first checks for 0, then creates a shared_ptr, rather than
correctly doing it the other way around.

>> There's nothing to help you remember which version allows 0 and which
>> doesn't. It could just as easily be the constructor which allows 0 and the
>> get() function which throws an exception.
> 
> Very subjective area. The interface feels right to me, although I know that
> many would disagree. I'm used to constructors throwing exceptions when they
> for some reason can't construct the object; query functions, on the other
> hand, especially something named get(), rarely throw.

Exactly. It *is* subjective. Having both semantics under two different names
creates a burden on the programmer to remember which behaves in which way;
it's no surprise that you can keep track of which is which since you made
the initial choice.

It's true that constructors customarily throw exceptions when they can't
construct an object; because they must! 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.

>> I stand by my original comment -- the constructor should not throw an
>> exception.
> 
> Why?

Even though I prefer the non-exception interface, my preference is even
stronger for a.get() and shared_ptr(a) to have the same semantics if we have
both.

If it was entirely up to me, I'd probably have the shared_ptr constructor
allow implicit type conversion, eliminate a.get(), and never use the
exception.

If we need an explicit operation to turn the weak pointer into a non-weak
pointer, I would probably name it make_strong() and make it a free function.
The analogy between shared_ptr::get() and weak_ptr::get() seems strained to
me. In the case of shared_ptr, it's a nearly deprecated operation that is
used to get a raw pointer, often for use in legacy programming interfaces.
In the case of weak_ptr, it's the way you do the main thing that weak_ptr
does -- make a pointer you can use. From the point of view of an implementer
they are similar, but not from the point of view of someone using weak_ptr.

    -- Darin