From: Kevlin Henney (kevlin_at_[hidden])
Date: 2000-07-13 12:54:39
In message <126.96.36.199.2.20000713103322.021126e8_at_[hidden]>, Beman
Dawes <beman_at_[hidden]> writes
>Kevlin Henney wrote:
> >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.
>The initial scope was smart pointers people had discussed on boost. No
>reason that can't be broadened, but we will just confuse ourselves if we
>try to work out too complicated an example the very first time we use this
OK, it's just that we did discuss the locking pointer variety. However,
I agree start with the simplest thing that is stable and that we
understand, and refine from there.
> >>ownership ( tightly-held // scoped_ptr
> >> | transferable // auto_ptr
> >> | shared // shared_ptr, linked_ptr, etc.
> >> | weak // ??? weak_ptr
> >> | copyable // copy_ptr
> >Also: 'unowned'.
>Hum... Is it still a smart pointer? Could you explain a bit?
Yup. Going back to square one (or should that be zero as it's C++?)
smart pointers are proxy objects that add management and access control
to a level of indirection, idiomatically appearing to support parts of
the built-in pointer protocol. A common application (and misconception)
is SPs for memory management. This is only one role that they can play:
checking, locking, loading, navigation, etc are others. Hence, most
iterators in the standard library are examples of smart pointers even
though they have no strong ownership semantics.
> >Would 'copyable' read better as 'copied'?
>Or 'copy'. 'copyable' isn't very good, for sure.
'copy' sounds best.
> >Also: 'none' -- not all SPs have anything to do with ownership.
>You're stretching my mind again. Could you explain? Oh, maybe I see, it is
>related to ownership::unowned.
>Now if I understand correctly, we should specify a constraint that
>ownership::unowned implies release::none. But isn't that the same
>thing? Maybe it should be specified as [release], that is, optional, with
>a constraint that it can't be omitted unless ownership::unowned. It's a
Sounds good to me! You are the one with the C&E knowledge :-)
> >>T-visability ( complete
> >> | incomplete-OK-if-trivial-dtor
> >> | incomplete-OK
> >> )
> >sp: T-visibility?
>Picky, picky. Fixed.
Sorry. Just in the middle of a whole pile of reviewing, and the reflexes
are still controlling my QWERTY access.
> >>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?
>I don't know. But we shouldn't go from the extreme of very little
>variation to the other extreme of variation just for its own sake. There
>would need to be a constituency (what C&E calls stakeholders) who claim to
>have a real need for a given feature.
>Another point is that features have what C&E calls the open/closed
>attribute, meaning new sub-features expected or unexpected.
>Is this a viable approach and in keeping with C&E?
Don't know yet! But it sounds good.
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