|
Boost : |
From: Kevlin Henney (kevlin_at_[hidden])
Date: 2001-07-21 12:15:18
> 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 :-}
>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.
Kevlin
____________________________________________________________
Kevlin Henney phone: +44 117 942 2990
mailto:kevlin_at_[hidden] mobile: +44 7801 073 508
http://www.curbralan.com fax: +44 870 052 2289
Curbralan: Consultancy + Training + Development + Review
____________________________________________________________
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk