> >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.
"Config feature" has nothing to do with what I was talking about. I may not want to use RTTI even if compiler suports it (and most does). The issue I have is that some implementations of RTTI cause significant runtime overhead even if never used (but compiled with it), that may not be acceptable. > >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. It would be good enough for me (and may be for many others). I do not like std::type_info based logic anyway. > >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. No. Macro that could be used only for convinience puposes. If we move default_reflection in separate header (that will include typeinfo) lexical cast users will need to include it separately. We could include it directly in lexical_cast.hpp and guard with macro BOOST_LEXICAL_CAST_USE_RTTI > >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 :-( Even if none of the above looks sound for you I still argue that lexical_cast *should not force* inclusion of typeinfo. It's not "inconvinience" - it's showstopper. It's much more important than providing specific type info. In majority of the cases one knows it anyway. > Kevlin Gennadiy. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost