|
Boost : |
From: Kevlin Henney (kevlin_at_[hidden])
Date: 2000-07-12 11:11:05
In message <4.3.2.7.2.20000712104116.00b89d98_at_[hidden]>, Beman
Dawes <beman_at_[hidden]> writes
>Using the technique described in
>http://www.egroups.com/files/boost/Feature+Modeling/feature_modeling.htm, I
>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
> release
> T-visability
> 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.
> size
> [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
Also: 'unowned'.
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
> )
sp: T-visibility?
>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
| detached-reference-count
| linked-handles
)
attached-reference-count
( invasive
| non-invasive
)
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.
>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
the object.
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