Re: [boost] any

From: Peter Dimov (pdimov_at_[hidden])
Date: 2000-09-01 11:41:26

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

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

In particular, op== and op< (should) continue to work fine. Of course op->
is meaningless, just like it's meaningless for a void*.

(The example I uploaded doesn't allow ref<void>; I had a version that worked
fine, but it looks like I broke it while fighting some g++ bugs. It can be
made to work, however, and I believe that with small changes it can be made
to pass your 'any' tests.)

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

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

> >> (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?
>
> >(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).

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? (*)

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.

(*) The great typeof(t + u) question. And more.

--
Peter Dimov
Multi Media Ltd.