On May 10, 2011, at 8:51 AM, "Stewart, Robert" <Robert.Stewart@sig.com> 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!