Boost logo

Boost :

From: Gennadiy Rozental (gennadiy.rozental_at_[hidden])
Date: 2003-03-22 14:37:53


> > There's absolutely no reason I can see to make the exact exception
> > type depend on the types concerned. Just use a straightforward
> > class, something along the lines of:
> >
> > struct bad_lexical_cast : std::exception
> > {
> > bad_lexical_cast(
> > std::type_info const& src, std::type_info const& dst)
> > : m_src(src), m_dst(dst) {}
> > char const* what() throw() { return "bad_lexical_cast"; }
> >
> > std::type_info const& src() const { return m_src; }
> > std::type_info const& dst() const { return m_dst; }
> > private:
> > std::type_info const& src;
> > std::type_info const& dst;
> > };
>
> Right. I see that Kevlin also suggest this approach in a later posting.
The
> original version of the extended exception used static initialization, as
> mentioned, which is why it was templated.
>
> I think this is a good approach.
>
> Regarding the other MSVC 6 warning given in the original report, Gennaro
> Prota has suggested using an explicit "!=", rather than relying on the
> implicit conversion from pointer to bool. This also avoids using a cast,
> instead.
>

> Regards,

> Terje

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

template<typename Target, typename Source,typename ReflectionPolicy=
default_reflection>
struct no_lexical_conversion : struct bad_lexical_cast
{
    virtual char const* src() { return
ReflectionPolicy::type_info<Source>() }
    virtual char const* trg() { return
ReflectionPolicy::type_info<Target>() }
}

struct default_reflection {
   template<typename T>
   char const* type_info()
   {
        static std::type_info ti = typeid(T);
        return ti.name().c_str();
   }
}

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*)

I could not afford to include <typeinfo> into my source and never do. And I
do not think lexical cast should force me.

Regards,

Gennadiy.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk