[boost] Re: MSVC++ 6.0 compiler errors with 1.30.0 (mostlylexical_cast.hpp)

From: Gennadiy Rozental (gennadiy.rozental_at_[hidden])
Date: 2003-03-22 17:07:09

> >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.