Re: [boost] Re: more flexible lexical_cast

From: Terje Slettebø (tslettebo_at_[hidden])
Date: 2002-08-22 17:31:48

>From: "Matthias Troyer" <troyer_at_[hidden]>

>On Thursday, August 22, 2002, at 12:40  PM, Alberto Barbati wrote:

>> Terje Slettebø wrote:
>>
>>> Would it really be an advantage to use "t=interpreter.str()" instead
>>> of "t
>>> << interpreter"? Performance, perhaps. Have you done any measurements,
>>> or
>>> something like that, to show that this specialisation is worthwile?
>>
>> It's not just a matter of performances here. "t=interpreter.str()" and
>> "interpreter >> t" do two completely different things. In particular,
>> the latter stops at the first whitespace while the former does not. In
>> fact, one thing that striked me at first when studying lexical_cast is
>> that with the current implementation, the expression:
>>
>> boost::lexical_cast<std::string>(std::string("hello, world"))
>>
>> not only does not return the string "hello, world" but throws an
>> exception because of the space. It's very counter-intuitive, IMHO.
>
>I agree with Alberto and also do not like these feature.

Nobody does, not even Kevlin. :) As mentioned in another posting, that's one
of the things that is fixed in the proposition. Another thing is support for
other character types, including wide characters. This is something the
original version doesn't handle, either. It also contains various
optimisations, bypassing the stringstream in many cases, when the source or
target is char, std::string, etc.

The updated version will be posted soon.

>I have patched
>myself
>a separate version which returns "hello, world" in this case, since I
>need
>this behavior in my applications. Is there any reason for not
>specializing
>lexical_cast for a target of std::string?

No. The above already works in the current proposition. However, as Alberto
pointed out, it's clear that one also need a special handling when the
target is std::string, even if the source is _not_ char *, std::string, etc.
Earlier, it only checked for those, as they were candidates both for
optimisation (bypassing stringstream), and possibility of whitespace.
However, it may be that there are other types that output spaces, as well.

Regards,

Terje