Re: [boost] [lexical_cast] char types and UDTs

Subject: Re: [boost] [lexical_cast] char types and UDTs
From: Olaf van der Spek (ml_at_[hidden])
Date: 2012-04-11 14:07:34

On Wed, Apr 11, 2012 at 7:12 PM, Eric Niebler <eric_at_[hidden]> wrote:
> On 4/11/2012 9:36 AM, Olaf van der Spek wrote:
>> On Wed, Apr 11, 2012 at 5:18 PM, Eric Niebler <eric_at_[hidden]> 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?

Not if you want to avoid copying the data.

> Besides, using std::iterator_range would not solve the problem because
> lexical_cast only knows about boost::iterator_range. Do you see?

Actually, I don't think std::iterator_range exists. I probably meant
boost::iterator_range.

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

Maybe, but lexical_cast isn't the only code that wants to consume
string-like types.
IMO this should be handled in a more general way.

-- 
Olaf