[boost] Re: weak pointers and cycles

From: Darin Adler (darin_at_[hidden])
Date: 1999-12-04 19:17:29

> 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.

> 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.

> 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.

> 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.

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.

    -- Darin