On 4/11/2012 9:36 AM, Olaf van der Spek wrote:
On Wed, Apr 11, 2012 at 5:18 PM, Eric Niebler <eric@boostpro.com> wrote:
You have to construct a string somewhere, don't you? If you have one already, you could use iterator_range<const char*> instead to avoid a copy.
Yes, I see that lexical_cast has optimizations for iterator_range<wchar_t const *> and a few other, sufficiently 'string-like' types. But sub_match essentially *is* a string-like iterator_range. (It's a std::pair of iterators.) I'm genuinely surprised
Is it? Does it have begin() and end() for example? Why not use std::iterator_range instead of std::pair?
Because the C++ standard says sub_match should inherit from std::pair. But does it matter? There are other 3rd party types that I'm sure users would like to adapt to lexical_cast. The docs just say a type needs a stream insertion operator. Shouldn't that be sufficient? Besides, using std::iterator_range would not solve the problem because lexical_cast only knows about boost::iterator_range. Do you see?
there's no way to tell lexical_cast that. Instead I have to just know (a) which are the magical types lexical_cast is optimized for and (b) for which it can determine the correct underlying stream character type (hint: the docs are unclear or out of date), and massage my type into one of those before calling lexical_cast. Why?
How could it automatically determine the necessary character type?
It can't be done automatically, but lexical_cast can expose the stream_char trait and make it a documented part of the interface. Users can specialize it for their types. -- Eric Niebler BoostPro Computing http://www.boostpro.com