Boost logo

Boost :

From: Early Ehlinger (earlye_at_[hidden])
Date: 2002-12-29 14:10:32


[Sorry for the top-posted reply... OE is giving me fits...]

This is an interesting argument. In other words, lexical_cast is, by
definition, conversion through a stream. Therefore, one cannot expect a
string with whitespace to exit as it went in.

Perhaps what is really needed is a different pseudo-cast, e.g.,
symantic_cast< >, which has different goals more in synch with what we are
trying to accomplish, which is conversion from any type to another with
minimized loss of symantic value.

--
-- Early Ehlinger CEO, ResPower Inc - Toll-Free : 866-737-7697 --
- RenderFarm - Lightwave , 3dSMax , Bryce , Maya , AfterEffects -
--- www.respower.com -- 200+ GHz Starting At USD$0.50/GHz*Hour --
----------------- SuperComputing For the Masses! ----------------
"I'm so busy programming my computer to let me be lazy, I never
get any rest!" - John Kaster
"Thomas Witt" <witt_at_[hidden]> wrote in message
news:200212291924.36397.witt_at_ive.uni-hannover.de...
Hi,
On Sunday 29 December 2002 01:29, Terje Slettebø wrote:
> > Is this the way lexical_cast is intended to work?
>
> No, Kevlin has acknowledged that this is a known problem with the current
> version of lexical_cast, the handling of whitespace in strings and
> characters.
I am still uncertain whether this is a problem with lexical_cast and whether
it should be fixed.
The stated purpose of lexical_cast is type conversion through string
representation. I think this is a simple but powerful concept.
To me the actual problem is not in lexical_cast but in the
std::basic_strings
stream operator semantics. Basically you cannot read strings containing
whitespace as a whole. I.e. the integrity of a string containing whitespace
is lost once you streamed it.
This is a fundamental if at  times undesirable property of std::basic_string
and char const* for that matter. I don't know whether it is a good idea for
lexical_cast to try to fix it.
Just my 2c
Thomas

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