On 4/10/2012 9:22 PM, Antony Polukhin wrote:
2012/4/11 Eric Niebler <eric@boostpro.com>:
There is an internal trait, boost::detail::stream_char, that lexical_cast uses to determine what the character type of the source is (if any). It's specialized on only a fixed number of types. Since it's an implementation detail, it can't be used to extend the set of types. Also, I tried specializing it. In past versions of Boost that just worked, but it doesn't anymore.
I think being able to extend lexical_cast to support types like (std|boost)::wssub_match is an essential feature. Thoughts on how to get there from here?
Specializing boost::detail::stream_char is not nice. Why just you don't specialize lexical_cast directly:
namespace boost {
template <class Target, class BiIter> Target lexical_cast(const sub_match<BiIter>& m) { return boost::lexical_cast<Target>(m.str()); }
} // namespace boost
Calling m.str() creates a temporary std::wstring object, which incurs a dynamic allocation and is slow. Speaking for my own library (xpressive), sub_match has an optimized stream insertion operator. It should be used. But my primary objection is below...
[Not tested]
Using this approach you will also get a faster version of lexical_cast (which does not copy data to STL stream and does not construct heavy STL stream objects). This approach is also described in lexical_cast trunk documentation, in section 'Tuning classes for fast lexical conversions'.
I'll add your question to the FAQ section of lexical_cast documentation.
Doesn't boost have a policy against adding overloads in the boost namespace? Perhaps not, but maybe it should. I know the std namespace has such a restriction. It seems dubious telling users to extend a library this way. A user should be able to do: Dst (*pfun)(Src const &) = &boost::lexical_cast<Dst, Src>; and expect that to "work". If there are a bevy of overloads, then that will end up calling a different function. -- Eric Niebler BoostPro Computing http://www.boostpro.com