Re: [boost] Re: Proposal: converting casts for 'any'

From: Corwin Joy (cjoy_at_[hidden])
Date: 2001-07-22 14:16:45

----- Original Message -----
From: "Kevlin Henney" <kevlin_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Saturday, July 21, 2001 12:15 PM
Subject: [boost] Re: Proposal: converting casts for 'any'

> >   From: "Corwin Joy" <cjoy_at_[hidden]>
> [...]
> >> This seems to be a potentially useful direction for the conversions
> >> library in general. For instance, a customisable conversion from A to
B,
> >> with any as a specific example of implementation.
> >
> >This sounds like a cool idea with some good potential.  I'm not quite
sure I
> >can visualize / understand exactly how this would work.  On the one
hand --
> >to do the 'any' conversions I had to dig into the structure of the any
class
> >a bit so in that sense what I have done is specialized.
>
> I did wonder about this: (1) the casting you are doing seems dangerous,
> (2) any_cast already provides the facility you need for your access, and
> (3) you are violating the 'private' contract of the class :-}

This is a good point.  What I am doing should be safe since I only cast to
the underlying type that the 'any' class tells me it holds.  But, I agree,
it would be better to use the any_cast<> here rather than doing the
equivalent code in my own routine.
>
> >On the other hand,
> >if you don't have an 'any' type class and know the exact type it seems
like
> >you would be better off using a templated cast such as numeric_cast
> >directly.  But, hopefully I am just missing the point here?
>
> I wasn't being particularly clear. By generalising I was thinking aloud
> about the mileage of providing a cast library that can be used in an
> application-specific way, ie registered_cast<T>(U). You provide a
> framework for registration and lookup that can then be tapped into by a
> registered_cast overload (would be partial specialisation, but...) of
> the appropriate type. In this case, where U is boost::any would be an
> example of applying the library.
>
> Haven't had the chance to consider this utility in depth, and the issues
> of introducing global state into an app -- coupling, threading, etc --
> but I think it's worth thinking about at least.

This sounds like a reasonable idea.  As you had mentioned this kind of thing
could also be useful in the units conversions library and possibly some
other places as well  so it might make sense to try to generalize the
structure a bit.  (I'll think about it some more and see how hairy this
makes things -- probably not too bad, however).

Corwin