From: Andrei Alexandrescu (andrewalex_at_[hidden])
Date: 2000-05-30 17:33:31
--- In boost_at_[hidden], "Miki Jovanovic" <miki_at_o...> wrote:
> I will be hard pressed to support this kind of generalization. I
> strongly believe that a class should do one thing and one thing
> (KISS). You talk about 160 different behaviours. If I want a
> shared_ptr, I do not want to have even to know of other 159
> behaviours. I have trouble explaining the smart pointer concept to
> some programmers, I can only imagine the headache of making them use
> a class that has 160 variations in behavior.
I predicted this concern. The number 160 scares people at first :o).
The behaviors are easily selectable with few policies. The user only
has to put together a typedef like:
It's really easy, and I think it actually makes smart pointer much
easier both to implement and to explain, because instead of dealing
with the syntactical stuff and the semantic stuff all at once, which
is *overwhelming* for smart pointers, you only focus on bite-sized
It took me a while to decompose smart pointer on various issues, but
then it was very easy to fiddle with it.
I think it would be much more awkward to have handle_ptr,
well, you get the idea.
> And this even does not touch the topic of standardising object
> access. Imagine if std containers had this configurability. You
> not be able to write a reusable piece of code, because depending on
> your 'policies' container would behave differently.
I'm afraid I don't understand this. If you use the pre-canned
policies, you get a combination of known behaviors.
By the way, I have a simple mechanism for converting classes that use
different policies, as long as the conversion makes sense. For
instance, you can assign checker pointers to checked pointers.
> Concept of a handle_ptr (or whatever you call it) is a very
> interesting one. This might find its way to boost quite easily.
I'd prefer a flexible smart pointer able to accommodate many
behaviors, to a plethora of rigid pointers that have to have lots of
template parameters anyway.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk