From: Peter Dimov (pdimov_at_[hidden])
Date: 2000-09-04 07:21:58
> >> 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. :)
> Err... <thinks>... <sidetracks> How about listing what you think are its
> defining features, and from that drawing a name that seems to capture
> this or at least part of it?
To paraphrase Scott Meyers, ref<T> is an object that is designed to act,
look and feel like the value it holds.
Unfortunately, due to technical constraints, I had to replace r.f() with
r->f() and added *r as a companion.
> >Perhaps I misinterpreted your original intent, however.
> A little, but the idea of a customised double and single dispatch engine
> was what I had in mind;
In this case, having a boost-accepted double dispatch engine would be a
> making any behave exactly like a statically-
> typed value was not -- that's what statically type values are for ;->
Not if you get handed an 'any' from somewhere else - e.g. interpreters. As
you said, static typing is not sufficient.
> However, I did not see this as part of the core any offering, ie it is
> something that a user can layer on top according to preference. I also
> would not support a combinatorial explosion of operations, eg int and
> double, char and string and char *, and so on.
I think that you should explain this extended_any concept in more detail.
How does the user layer an operator+ on top of any? How are the possible
conversions controlled by the user? How is any(int) + any(std::string)
handled, i.e. is this an int or a string?
-- 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