From: Paul Baxter (paul_baxter_at_[hidden])
Date: 2000-05-30 18:10:55
From: "Andrei Alexandrescu" <andrewalex_at_[hidden]>
> [about SmartPtr]
> > (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
> > possible
> > 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.
While I certainly agree with KISS, I find the idea of having a few aspects
of a smart pointer's behaviour that can be [independently] juggled to be
more appealing than say 15 - 20 possible common smart pointer specialisms
A shared_ptr would be nailed down by 6 aspects of behaviour, but that
knowledge can later be reused when learning about other smart pointers.
Part of my problem is that there are a lot of smart pointer behaviours which
are needed in larger programs.
Learning lots of specialisms is only useful if you gain significantly in
performance over a more general concept.
My main concerns would be the run-time cost of having this flexibility over
hand-crafted solutions and whether a suitable common interface is possible
for potentially such a large variety of smart pointers.
At present the term smart pointer is often used very loosely and because of
this I have found documentation of all the issues fragmented at best.
The prospect of combining Andrei's take on the problem with the lessons
already learned to get a coherent set of smart pointers is appealing. (If
Not only will it focus on what behavioural aspects need addressing but it
might nail down in one place the range of problems a smart pointer is
Of course it is difficult to judge without seeing some test cases and
The other issue is licensing and coding guidelines.
1) Do/will your submissions meet the licensing terms for inclusion into
boost? i.e. free for commercial/non-commercial, modifiable etc.
2) I'm sure the code has a style for inclusion in your book (which I eagerly
await) but which I suspect may not be quite the same as boost.
Would you be willing to modify the code for inclusion (in exchange for the
additional constructive criticism :) ) or is that something you'd like to
see someone else do?
I for one look forward to something that brings together a lot of the smart
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk