Re: [boost] any

From: Kevlin Henney (kevlin_at_[hidden])
Date: 2000-09-01 12:13:52

In message <001f01c01433$7a1bbe20$130524d4_at_pdimov>, Peter Dimov
<pdimov_at_[hidden]> writes
>> >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.
>
>A question of terminology, I'm afraid. What's the definition of a smart
>pointer? 'any' doesn't overload op-> and doesn't look like a pointer, but it
>acts exactly like a cloning smart pointer.

Well, what a smart pointer is is fairly well understood, and any
definitely doesn't qualify: it doesn't look like one, doesn't behave
like one, doesn't quack like one, etc. It uses cloning as an
implementation mechanism, but that doesn't make it a smart pointer or
offer its facilities for cloning to the public -- it's encapsulated.

>> >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.
>
>The only difference in behaviour is that operator* is impossible, because
>C++ doesn't allow a reference to void. (Pity.)

Pity indeed. However, ref<void> does not offer polymorphic access to
types, and its use and role are quite different to a ref<PolyType>.

>> >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 ;-)
>
>Yes. I deliberately don't want to call ref<> a smart pointer. A smart
>pointer should point to something, not hold it. 

Not necessarily. If you haven't already looked, check out Beman's
feature model for smart pointers.

>I had to make ref<> look
>like a pointer because, as you pointed out, operator.() can't be overloaded.

Yes, but at the end of the day it is like (1) a pointer, and (2) not a
ref :-}

>Again, a question of terminology. Call 'ref' cloning_ptr if you like. This
>doesn't change the concept.

Understanding a concept often starts with its name. The reason I am
relating to it as a cloning pointer is that is the more conventional
terminology for it, and I that is how I have seen it used.

>> 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).
>
>I'm afraid I still don't get it. How would you define an arbitrary set of
>operators on a class? And how is op+ supposed to add two any's that hold
>different types? (*)

Need not be arbitrary, but it is up to the user defining the traits. In
the simplest case, do no conversion and throw an incompatible type
exception (or just return false for all conversions), hence why I would
say that this is a different concept again.

>That's why I constrained ref<> to op== and op<. First, I can easily define
>how they should behave when applied to different types, and second, I can
>made them work without the user defining any traits classes.

I'm talking about a different type again here: (1) any, (2) cloning_ptr,
(3) what I referred to in the previous para.
____________________________________________________________

  Kevlin Henney                   phone:  [phone]
  Curbralan Ltd                   mobile: [phone]
  kevlin_at_[hidden]            fax:    [phone]
____________________________________________________________