Re: [boost] any

From: Kevlin Henney (kevlin_at_[hidden])
Date: 2000-09-02 04:10:16

In message <005c01c0143c$979e4860$130524d4_at_pdimov>, Peter Dimov
<pdimov_at_[hidden]> writes
>I agree. The name is important. I just don't think that ref<> neatly fits
>the definition of a cloning smart pointer.

I agree that ref<> itself is not a cloning pointer, but from my
perspective the role it can play overlaps strongly. So a clearer name
would be a start.

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

I don't intend to leave it all up to the user :-) In this I meant, we,
as library writers, can provide the basic mechanism and in a user role
provide a set of standard conversions, eg interoperating numerics and
interoperating text types (char, char *, string).

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

And it's not always desirable: int + long is desirable, but int + string
is always a pain. Customisability could be achieved through a template
parameter that defined the relevant traits to use.
____________________________________________________________

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