|
Boost : |
From: Kevlin Henney (kevlin_at_[hidden])
Date: 2000-09-01 09:00:54
In message <006d01c01411$b72308e0$480524d4_at_pdimov>, Peter Dimov
<pdimov_at_[hidden]> writes
>> For this I have tended to use a cloning smart pointer, so that copy
>> semantics are deep. Operational usage is pointer-like, because we can't
>> overload operator., so I tend to classify it as a smart pointer.
>
>But ref<T> is a cloning smart pointer. So is any, for that matter. :)
Well, any uses cloning internally, but it's not a smart pointer.
>In C++
>we are limited to op-> and smart references are impossible.
Generic smart references are impossible, but specific ones are OK :-)
>The difference is that (1) you can use ref<> as is with standard containers
>and algorithms and it just works, and (2) you don't give raw pointers
>(obtained with new) to ref<>, it takes the values themselves.
I think this might be one of the features that can be controlled in
Beman's initial feature model for smart pointers.
>Then I realized that ref<void> can (strictly speaking, can be made to) hold
>any value (I wasn't aware of your 'any' class at the time.)
It seems to behave quite differently between the two cases, which
confirms for me that we are talking about two concepts.
>> In this case, providing operator== and operator< for a cloning pointer
>> does the trick.
>
>ref<> is a cloning pointer and I did provide op== and op<. :)
In which case, my favourite spellings for a cloning pointer are
cloning_ptr and clone_ptr ;-)
>No, it's not a problem per se. The point is that I didn't need <typeinfo>.
I think it's a worthwhile dependency in the sense of reuse: It reduces
amount of code and amount of new stuff that a developer needs to learn.
>> (1) Should we reopen the case for (or against) a cloning pointer? IIRC
>> there was some discussion on this earlier this year / late last year,
>> and then it fizzled out.
>>
>> (2) Look at variant value class distinct from any that is more
>> permissive in its operations, ie not just a passive container. Peter,
>> interested in taking this further?
>
>(1) A polymorphic value type is useful, can there be any debate on that?
I wouldn't have thought so, but I couldn't recall what the debate had
been!
>(2) Would you mind to elaborate further on that?
A class that allows arbitrary values to be held, but also supports
operators (potentially arbitrary set if we get our overloads and trait
classes right).
>In summary, do you think that it will be worth the effort to unify any and
>ref<T>, supporting the current idioms of ref<T> as a cloning value-based
>smart pointer and any == ref<void> as, well, a cloning value-based smart
>pointer without a common base requirement? Or these two concepts should
>remain separate.
I think these are all distinct concepts as they behave differently and
are used quite differently in each case.
____________________________________________________________
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