Hi Antony, Thanks for your response. Antony Polukhin wrote:
There are a lot of libraries, that can have tuned conversions for lexical_cast. The bad thing, is that lexical_cast can be customized ONLY via overloading operator>>(stream&) and operator<<(stream&), and that is not very fast. That is the design. As simple, as possible. Multiple customization points will make the design obfuscated.
It would be also a bad idea, to include a lot of different library headers to lexical_cast.hpp (will increase compilation times, add unnecessary dependencies...)
Makes sense. But, IMHO, it's worth optimizing codes for string ranges, since string ranges are often used in string algorithms.
If you assume, that it is safe to use &iter_rng.front() (extremely unsafe!),
IIUC, the main concern to implement optimized code is that how to obtain begin and end pointer to CharT from `iter_rng` safely. With C++11-conforming standard library, it is safe to implement bool operator<<(::boost::iterator_range<std::string::iterator> const& str) { if (!str.empty()) { start = const_cast<CharT*>(&str.front()); finish = start + str.size(); } else { start = 0; finish = 0; } return true; } because `&*(s.begin() + n) == &*s.begin() + n` (`s` is an object of std::basic_string<…>) is guaranteed. But, in C++03, the above code is not safe; the standard does not guarantee that std::basic_string<…> is stored contiguously (though many standard library implementations store it contiguously). Regards, Michel