[boost] Re: weak pointers and cycles

From: Darin Adler (darin_at_[hidden])
Date: 1999-12-04 22:05:57

Thanks for your comments, Greg. They are helping me think more clearly about
the issues.

>> Yes. This is a major flaw in my idea. It's hard to do much with a class
>> without a default constructor in C++; the standard containers seem to insist
>> on one.

> Right.  That's why I am disinclined to make your "strong pointer"
> the default Boost version.  It seems you can get what you need by
> just inheriting from shared_ptr and making the dangerous operations
> private.  Perhaps we can do that in boost as well.

An alternative is to have the default constructor construct an instance of
the pointed-to type with (new and) its default constructor. I'm not sure if
that's a good idea either; seems it might be a bit inefficient.

>> I don't intend to test for null on every dereference, which is why I have my
>> pointers that are guaranteed not to be null. For me it's about the
>> programming model. I'd like a way to express that a pointer is never null
>> other than a comment saying so.

> Oh.  I thought that was what you meant by "optional strong pointer --
> This can hold a strong pointer or null. It uses an interface that
> promotes checking for null."

What I meant is that you don't get at the value of the "optional strong
pointer" without first checking if it is null. After you do that, you call
"get()" and it returns a "strong pointer".

When I say the interface "promotes checking for null", I mean that it
promotes a style with explicit checks for null in the client code. It would
be considered bad style to dereference an optional pointer (yielding a
non-optional one) without checking for null explicitly just before that.

>> If your quibble is about whether the get() operation throws an exception or
>> not, that's not big deal. The point of the proposal is that you don't do
>> get() unless you've already checked for null.

> Sorry, but are you talking "strong pointer" or "optional strong pointer"
> here?

I was talking about "optional strong pointer". In "strong pointer", there's
no need to check for null at all (the implementation or the client), because
the underlying dumb pointer can never be null.

Converting a "strong pointer" to a dumb pointer is deprecated in what I
described, but that operation what's currently called "get()" in the
shared_ptr class.

Getting the value of a non-null "optional strong pointer" yields a "strong
pointer". I was using the name "get()" as a straw man suggestion for that
operation too.

    -- Darin