Re: [boost] [review] string convert

Subject: Re: [boost] [review] string convert
From: Matthew Chambers (matt.chambers42_at_[hidden])
Date: 2011-05-05 16:56:26

On 5/5/2011 3:17 PM, Vicente BOTET wrote:
>
>
>
>> Message du 05/05/11 19:48
>> De : "Stewart, Robert"
>> A : "'boost_at_[hidden]'"
>> Copie à :
>> Objet : Re: [boost] [review] string convert
>>
>> Vicente BOTET wrote:
>>>
>>> are we discussing here a generic interface from type-to-type or
>>> one that uses an intermediary stream to make the conversion?
>>
>> I've been considering it the former. Why does using a stream to make the conversion affect that?
>
> The fact that we want to add some formatting parameters, apply manipulators and so on to a generic interface disturb me.
>
>> - T convert_cast(S, formatting = none); can throw
>> - T convert_cast(S, T, formatting = none)
>> - optional name_me_1(S, formatting = none)
>> - optional name_me_1(S, T, formatting = none)
>> - pair name_me_2(S, T, formatting = none)
>
> I would prefer to don't pay for these defaulted parameters in the generic case.
>
> Maybe I'm wrong, but the manipulators are only useful when converting from a string or to a string. If this is the case, all the stream stuff should be moved to a string conversion interface. I would even prefer that the stream part stay away and independent. In another post I proposed to use an istream proxy when converting from a string to a type
>
> as_istream(str)>>  std::hex>>  i;
>
> For conversions from a type to a string, we can use an ostream proxy, which is implicitly convertible to string.
>
> string str = as_ostream()<<  std::hex<<  i;
Conversions from strings to primitives and vice versa will vastly outnumber other type-to-types. If 
we're going to bias the interface in some way, I believe in doing it for the general case. And 
unless I'm missing something, the as_xstream syntax has the same implicit conversion problem that 
the convert<T>::from<S>() syntax has.

Other kinds of type-to-type conversion that aren't better served by numeric_cast (unless you're 
proposing to wrap numeric_cast with boost.conversion?) are practically edge cases, aren't they? We 
can allow the interface to support them, but we shouldn't reduce it to the lowest common denominator 
when the general requirements are higher.

Also, the string conversion will be optimized for the common cases: integral<->string and 
floating<->string. Lexical_cast's current stream-only implementation won't suffice. Basically, I 
think type-to-stream-to-type should be the fallback mechanism if no specialization is available. And 
of course sometimes even that fallback mechanism will fail with UDTs.

-Matt