Boost logo

Boost :

From: Kevlin Henney (kevlin_at_[hidden])
Date: 2000-07-13 12:54:39

In message <[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
>modeling technique.

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
>learning process!

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, gregod at, cpdaniel at, john at