[Boost-users] non nullable smart pointers

Subject: [Boost-users] non nullable smart pointers
From: Brendan Miller (catphive_at_[hidden])
Date: 2008-11-14 21:16:51

I've been interested in non nullable smart pointers for a while. I
noticed a thread I wanted to check if anyone was still interested in
doing it:
http://lists.boost.org/Archives/boost/2008/04/135616.php

This seems like a worthwhile activity. Null is a legacy element from C
that essentially breaks type safety.

C++ added references as a way of moving people away from null, but T&
obj style references have a number of problems:

1. They have value semantics, which is just plain annoying considering
they are *called* references.
2. They use obj.member notation instead of obj->member.

1 is just not usually desireable, and 2 means that there's no way to
write a "smart reference" that uses ref.member notation.

With that in mind what would a nonnullable pointer be named? I've seen
one implemented as a "checked_ptr", but that's a mouthful and doesn't
account for the fact that several variations on memory management
scheme are needed.

I'm thinking:

ref<T> myObject; // for a non-nullable pointer with no special memeory
management
scoped_ref<T> myObject; // for scoped_ptr style memory mangement
shared_ref<T> myObject; // you get the idea.

I'm also aware of a number of problems with the shared_ptr
implementation, specifically that it creates a second allocation for
the counter (the counted body problem), and that it always does
synchronization, which might have performance overhead for single
threaded code (someone else might know more about that than me). It
migth be nice to start fresh on these designs now that some
perspective has been gained.

For the counted body problem I was thinking of creating a
make_shared_ref that would create an object and counter adjacent to
each other (just put them in the same struct). I put together some
proof of concept tempaltes a whie ago and having make_shared_ref<T>
behave exactly like new T was somewhat problematic due to overloading
issues. Also, you'd need to keep around an extra function pointer in
the counter object to delete the struct all together or delete the
object seperate object and counter (if they are non-adjacent) and I"m
not sure about how that would stack up performance wise.

Brendan