[boost] Re: Smart Pointers - (many) thanks and (some)questions

From: Andy Glew (glew_at_[hidden])
Date: 1999-12-30 21:53:57

Ah, to hell with it!

Template argument creep is ugly, ugly, ugly....
(it's a pity that we don't have keyword arguments....)

Boost should just define a shared_ptr API
that makes no multithreading guarantees.

The reference implementation should not be MT safe,
neither mutexed nor even read/write atomic.

Boost might consider a "standard" API for minimal
multithread operations - lock acquisition and release -
as somebody posted an example.

Using this, Boost might consider a mutexed_ptr<T>
wrapper, and perhaps mutexed wrappers for a number
of other data structures, such as STL containers.

Implementors should be encouraged to provide different
flavours of shared_ptr, if they feel aggressive, including
mutexed, and, if they are very, very, skillful, read/write
atomic but not mutexed versions.  Selected by conditional
compilation, include path games, or whatever...

The latter allows shared_ptr to be more of a drop-in 
replacement for a scalar pointer, but this is a losing battle:
C++ smart pointers aren't pointers. Lack of low-cost write
atomicity is just yet another difference between smart pointers
and ordinary pointers.

If different shared_pointer implementations are encouraged.
it might be useful to include multithreading support as a 
query operation - a property of type traits.  Is it already there?
Queries to indicate whether an implementation is
    semantic
       a) totally multithread safe - the semantic equivalent of mutxed
    performance
       b) single entry, i.e. mutexed (a performance query)
       c) multiple simultaneous readers / single writer