Re: [boost] [review] string convert

Subject: Re: [boost] [review] string convert
From: Matthew Chambers (matt.chambers42_at_[hidden])
Date: 2011-05-09 17:54:40

On 5/9/2011 4:10 PM, Stewart, Robert wrote:
> Matthew Chambers wrote:
>> When you say "stream-based main logic" do you mean that it
>> should appear to be using streams, but that it doesn't matter
>> if it really does?
>
> No.  I meant that all of the stream-based conversions are done via the stream_converter class.  It is the customization point and, therefore, the common place in which to handle any special cases for the stream-based conversions.
>
> Likewise, the converter class is the customization point and the common place in which to handle special cases for non-stream-based conversions.
>
> That approach means that all conversions are handled by one class template for each of the two conversion styles.  The various function templates are merely wrappers which provide type deduction and things like exception throwing and varying return types.
>> It's reasonable to develop optimized string<->numeric
>> converting code that respects locale and manipulators, so I
>> don't think we should exclude the possibility of such
>> implementations.
>
> If such logic can be added to provide conversions as if a stream was used but without using a stream, then it fits as a stream_converter specialization.
OK, that sounds good.

>> If we're going to create two APIs, I'd rather have one for
>> string<->numeric conversion and one for type<->type conversion.
>> I also don't understand the shift from "convert_cast" to "as".
>> It isn't intuitive why one uses streams and the other doesn't.
>
> My idea was that the convert_cast part of the interface was not stream-based and, therefore, incorporated Vicente's ideas, and that the "as" part was stream-based and, therefore, incorporated Vladimir's ideas.
I understand that, I just meant that the nomenclature doesn't suggest that distinction. Why should 
the interface be different at all (except for the manipulators)? It seems you've come to this idea 
in another post.

>> I agree we need to support multiple manipulators, but yuck! The
>> nicest way I can think of to do that is with separate
>> parameters for each manipulator category:
>>
>> int i = convert::as<int>("+42", (_showpos=true,
>>     _base=ios::oct));
>> string s = convert::as<string>(123.456, (_scientific=true));
>>   // or _float=ios::scientific ?
>
> Do those apply to the insertion into or extraction from the stream?

Using a single stringstream for a string<->non-string conversion, I'm not sure it makes a 
difference. The only case I thought of where it would matter is a string<->string, i.e.
"42"(dec)<->"2A"(hex)
"123.456"(fixed)<->"1.23456e+2"(scientific)

Maybe I'm overlooking something obvious.

-Matt