Re: [boost] any

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

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

And since ref<T> is a cloning smart pointer, it somehow offers its
facilities for cloning to the public and is not encapsulated; yet ref<void>
== any. A contradiction.

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

Yes, they are. Consider this, however: void* doesn't offer polymorphic
access to types, PolyType* does; yet they are both pointers and I can write
generic code that operates on both, if I so desire.

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

No, it's not exactly like a pointer. p1 == p2 has a different meaning for
pointers. Ditto for p1 = X(1).

It may not be a 'ref', but it's not a pointer either.

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

I agree. The name is important. I just don't think that ref<> neatly fits
the definition of a cloning smart pointer.

> >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 the easy way out; however, the user that wants to add any(int) and
any(long) would expect it to 'just work.'

To require user defined traits for all type combinations would be "a bit
excessive." :)

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

Oh I know. I'm using ref as an example of a value-holding type that
implements op== and op<. The point is, these two operators are easy to
define, but others are not.

The ideal case would be for

any(T) + any(U)

(make this extended_any if you like, any is shorter)

to look for a matching op+ and return

any(typeof(t + u))

but this is very difficult to achieve, if possible.

--
Peter Dimov
Multi Media Ltd.