Boost logo

Boost :

Subject: Re: [boost] [review] string convert
From: Gordon Woodhull (gordon_at_[hidden])
Date: 2011-05-10 10:33:22


On May 10, 2011, at 8:51 AM, "Stewart, Robert" <Robert.Stewart_at_[hidden]> wrote:

> Gordon Woodhull wrote:
>>
>> I am not sure if one unified function is possible, but I wonder
>> if one way to define a "best conversion" function, would be to
>> drop lexical_cast's type-to-stream-to-type default, which is
>> IMHO what really messes up thinking about type-to-type and
>> string-to-type/type-to-string in the same sentence.
>>
>> And so convert_cast<T>(S) would use something like Convert if S
>> or T is string (with any behavior determined by arguments), and
>> something like Conversion if neither is.
>>
>> This is also in line with Antony Polukhin's improvements for
>> lexical_cast which are mostly not lexical IIUC. I think people
>> and their metaprograms expect a conversion function that is not
>> actually lexical unless S or T is string.
>
> At first blush, I agree that, without a string, there's no "lexical" in the cast. However, a UDT might contain a string and thus rely on the stream behavior and formatting. That, could, of course, be managed with a trait that indicates whether a type requires a stream for its conversion. Specializations for string types would provide the default behavior, but authors of UDTs can specialize the trait as needed.

This seems like a case of non-lexical cast recursing into a lexical cast. To take a concrete example, say you want to convert pair<string,string> to pair<int,int>. Vicente's library already automatically decomposes this into two string->int conversions.

Those might need manipulators, so it seems a unified interface would be helpful here, so that eg std::hex can be passed through Vicente's library to where it's needed in Vladomir's.

But is this opening up another can of worms? What about converting paid<string,int> to pair<int,string> ? Now we're back to needing both in and out manipulators, for a different reason!

>


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk