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
> 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
> 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.
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
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
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk