From: Kevlin Henney (kevlin_at_[hidden])
Date: 2000-07-12 11:11:05
In message <184.108.40.206.2.20000712104116.00b89d98_at_[hidden]>, Beman
Dawes <beman_at_[hidden]> writes
>Using the technique described in
>have taken a first cut at building a smart pointer feature diagram.
Thanks for putting this summary up. Have been following the C&E stuff
from a distance, and what with these postings and the timely arrival of
the book, even now staring at me across the table in its distinctive B&W
cover, seems I ought to give it a deeper look.
>----- Smart Pointer Feature Diagram ----
>Draft of 12 July 2000
>smart-pointer ( ownership
> operations // dereference, get, etc.
I think that dereferencing will open up a whole set of possibilities, ie
result as raw pointer, some other kind of proxy (eg for locking), etc.
> [multi-ptr-aquisition-safe] // shared-in-ptr
>ownership ( tightly-held // scoped_ptr
> | transferable // auto_ptr
> | shared // shared_ptr, linked_ptr, etc.
> | weak // ??? weak_ptr
> | copyable // copy_ptr
Would 'copyable' read better as 'copied'?
>release ( non-array
> | array
> | user-supplied
Also: 'none' -- not all SPs have anything to do with ownership.
>T-visability ( complete
> | incomplete-OK-if-trivial-dtor
> | incomplete-OK
>operations ( with-conversion-to-T-star
> | without-conversion-to-T-star
Is this to be extended to include the shopping list of possibilities
available for smart pointers or is it just for conversions?
>// Choosing a size forces some of the other features.
>// Likewise, Choosing some of the other features forces size.
>// This may be an example of an "aspect"; I need to read C&E more
>// to be sure
>size ( one-ptr // scoped_ptr, auto_ptr, copy_ptr
> | two_ptr // shared_ptr
> | three_ptr // linked_ptr
>shared ( invasive-reference-count // shared_in_ptr
> | separate-reference-count // shared_ptr
> | linked-list // linked_ptr
Following slightly more traditional classification, and extending:
shared ( attached-reference-count
countable_ptr at http://www.boost.org/more/count_bdy.htm is an example
of a non-invasive attached-reference-count in this reckoning.
And where detached-reference-count == separate-reference-count.
> ( direct // shared_ptr
> | indirect // like shared_ptr but ptr stored with count
There is another possibility for truly separate counting, where the
count is maintained quite independently of the handle, the body, or an
additional counter body, ie a manager object deals with the count and
This closely follows the reference counting classification I sketched
out and revised with Jim Coplien earlier this year on the back of an
envelope (or moral equivalent) in a bar at OT2000. Don't know whether
that's a good sign or not!
Kevlin Henney phone: +44 117 942 2990
Curbralan Ltd mobile: +44 7801 073 508
kevlin_at_[hidden] fax: +44 870 052 2289
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk