|
Boost : |
From: Kevlin Henney (kevlin_at_[hidden])
Date: 2003-03-22 15:12:25
In article <b5ie28$oic$1_at_[hidden]>, Gennadiy Rozental
<gennadiy.rozental_at_[hidden]> writes
>
>Sorry to interfere to this fine discussion, but from my standpoint
>introduction of std::type_info into lexical_cast is a big problem. I usually
>compile my program with noRTTI flag effectively making any program using new
>lexical cast fail to link..
OK, this is a new twist. Not one that can be addressed out of the box,
however: there is no config feature test that addresses this since, as
the config docs state, there is no accommodation for disabling now
commonly supported C++ features such as RTTI.
>Would you want to supply type information you
>may do it like this:
>
>struct bad_lexical_cast {
> ...
> virtual char const* src() = 0;
> virtual char const* trg() = 0;
>};
This would not be a massive improvement since the types would be, once
again, expressed as text rather than as program entities, ie type_info
objects.
>Now, question remains how user will customize ReflectionPolicy. I see at
>least 2 ways:
>1. Add third template parameter to the lexical_cast with default value
>2. Use global trait (in this case you may return customizable type from src,
>trg functions instead of char const*)
Neither of these sounds particularly attractive, I'm afraid, and would
still require config-level feature support.
>I could not afford to include <typeinfo> into my source and never do. And I
>do not think lexical cast should force me.
If you can make a case for introducing a standard config feature test
for RTTI this may be something we could consider using in lexical_cast.
Otherwise, apologies for the inconvenience :-(
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