From: Beman Dawes (beman_at_[hidden])
Date: 2000-07-13 10:12:39
Kevlin Henney wrote:
>>----- Smart Pointer Feature Diagram ----
>>Draft of 12 July 2000
>>smart-pointer ( ownership
>> operations // dereference, get,
>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
>> [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
Hum... Is it still a smart pointer? Could you explain a bit?
>Would 'copyable' read better as 'copied'?
Or 'copy'. 'copyable' isn't very good, for sure.
>>release ( non-array
>> | array
>> | user-supplied
>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
>>T-visability ( complete
>> | incomplete-OK-if-trivial-dtor
>> | incomplete-OK
Picky, picky. Fixed.
>>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. Maybe
operations should be identified as 'open' and then diagrammed like this:
operations ( basic-ops, optional-ops[ conversion-to-T-star ] )
then if operator-foo comes along, the diagram changes to:
operations ( basic-ops,
optional-ops[ conversion-to-T-star + operation-foo ] )
In other words, there are four possible optional-ops configurations:
both conversion-to-T-star and operation-foo
Is this a viable approach and in keeping with C&E?
I've run out of time; there's no lack of interest in your remaining points.
But let's do continue the discussion.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk