Re: [boost] Smart Pointer Feature Model

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

In message <4.3.2.7.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 
>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.

Yup.

>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.

Agreed.

>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:  [phone]
  Curbralan Ltd                   mobile: [phone]
  kevlin_at_[hidden]            fax:    [phone]
____________________________________________________________