[boost] Re: weak pointers and cycles

From: Greg Colvin (gcolvin_at_[hidden])
Date: 1999-12-04 16:37:42

From: Darin Adler <darin_at_[hidden]>
> 
> My motivation for using smart pointers is to delete the referenced object
> when it's no longer in use, and to avoid two pitfalls of normal pointers:
> 
>     1) invalid pointers after an object has been deleted
>     2) null pointers
> 
> The two pitfalls above come into play any time you use the * or -> operator.
> Every time you use * or -> you must have some guarantee that the pointer
> still points to an object. I like smart pointers because they guarantee that
> * or -> is legal. Because of these goals, I'd like these kinds of smart
> pointers:
> 
>     1) strong pointer -- The holder of this pointer owns the object and
>     knows it won't be deleted. This type can not hold a null pointer.

So it has no default constructor?

>     2) weak pointer -- The holder of this pointer knows the object won't be
>     deleted, because it has some higher-level knowledge about the object
>     lifetime. For example "this object is owned by another object, which will
>     delete me first" or something like that. If the underlying object is deleted
>     while there's an outstanding weak pointer, an exception is raised.

This is an interesting and useful interface, but it isn't what I
think is usually meant by "weak pointer".  What you want is usually
provided by some sort of notification callback, which is missing from
my current weak_ptr.  For example, a common use of weak pointers is
in a cache where the weak pointer is removed from the cache when the
object pointed to is destroyed.

> Neither of these would ever be null. To handle the kind of pointer that can
> be null, I'd have two other types.
> 
 >     3) optional strong pointer -- This can hold a strong pointer or null. It
>     uses an interface that promotes checking for null.
>     4) optional weak pointer -- This can hold a weak pointer or null. Unlike
>     a weak pointer, if the underlying object is deleted, this will just become
>     null.
> 
> The optional strong and optional weak types would have an interface where
> you can check if the pointer is null or not (call it good() or empty()?),
> clear the pointer (call it clear()?) and get the pointer (call it get()?).
> The get() operation would raise an exception if the pointer is null and
> would return one of the non-null smart pointer types. There wouldn't be any
> * or -> operator for these types, so in a way they are not really smart
> pointers, but rather holders for smart pointers.
> 
> The auto_ptr, scoped_ptr, shared_ptr, cyclic_ptr, and weak_ptr classes as
> they currently exist fall short for me because they all allow null pointers,
> which are almost as difficult to deal with as invalid pointers are.
> 
> Thoughts?

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

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.  Of course you can always parameterize, but I'm
resisting that until I am very clear on the concepts to parameterize
on.

Another problem with paramaterizing is that it creates a barrier to
communication in a large program.  If shared_ptr<T> is just one type
then you can write functions for T that traffic in shared_ptr<T>
without having to parameterize those functions too.  But if you really
have shared_ptr<T,Impl> then you have to either parameterize on Impl,
or insist that your clients use shared_ptr<T,Impl> too, or else they
must parameterize on Impl.  That may not be a problem in a program that
is already written in a "generic" style, but it may well be a problem
in a program written in a more "object-oriented" style.