Re: [boost] any

From: Peter Dimov (pdimov_at_[hidden])
Date: 2000-09-04 05:54:38

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

I'm open to suggestions. :)

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

int + string would throw an exception in the scheme I had in mind, because
int + string doesn't compile in the statically typed case.

Let me elaborate. Consider any::operator+:

any const operator+(any const & a1, any const & a2)
{
    return lookup_operator_plus(a1.type_info(), a2.type_info())(a1, a2);
}

This should look familiar - it is a double dispatch engine. Which is no
surprise, because any is a 'polymorphic' class. Its static type is 'any',
but its 'dynamic type' is that of the value last stored in it.

[Aside: unary operators would use a single virtual dispatch engine. Compare
this to ref<T>, which reuses the language facilities for single dispatch.]

A double dispatch engine needs to know about all the possible overloads;
this is implemented by registering the functions with it beforehand.

Now think about the number of registrations needed for the standard op+. :)

Worse, when you add an user-defined type like, for example, this one:

class udt
{
public:
    operator int() const;
};

the number of registrations that the user is required to supply is similarly
big.

Cases like

int i;
std::string s;

s + (char)i;

also deserve a deeper look.

So I conclude that making any behave exactly like the statically-typed
values is very difficult.

Perhaps I misinterpreted your original intent, however.

--
Peter Dimov
Multi Media Ltd.