[boost] Re: weak pointers and cycles

From: Greg Colvin (gcolvin_at_[hidden])
Date: 1999-12-04 19:51:35

From: Darin Adler <darin_at_[hidden]>
> > So it has no default constructor?
> 
> 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.

> > This is an interesting and useful interface, but it isn't what I
> > think is usually meant by "weak pointer".
> 
> Understood. If you read further in my original message and see what I call
> "optional weak pointer" you'll probably recognize what you would call a weak
> pointer. It's not the name that's important to me, it's the semantic.

Agreed.

> > I don't like the performance implications of testing for null on every
> > dereference, and a shared_ptr will be null only on default construction
> > or explicit zeroing out, so I don't see why nulls should be so hard to
> > deal with.
> 
> 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."

> > On most modern systems you can install a signal handler to
> > trap references to null pointers and throw an exception if that is what
> > you want.
> 
> 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?

> A signal handler for this is not an easy thing to do on all the systems I
> program on. And I don't want an exception. I want to already know that the
> pointer is not null. The exception only comes up when you use the class
> incorrectly, and could be an assert instead.
> 
> There is not a portable way of doing something defined when you dereference
> a null pointer, so I want to write programs that are guaranteed not to run
> into this problem.
> 
> > The more general struggle for me is finding a way to incorporate the
> > various kinds of smart pointers that people want into a reasonably
> > simple framework.
> 
> I agree. That's why I tried to describe smart pointer requirements rather
> than a specific implementation. I was hoping to clarify my needs from a
> smart pointer design rather than advocating a specific approach.

Yes, I appreciate that.  Thanks.  But remember we already have shared_ptr
and scoped_ptr, and need to not break them.