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:
operator int() const;
the number of registrations that the user is required to supply is similarly
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk