Re: Fw: [boost] Re: Complex type failure with boost::lexical_cast

From: Kevlin Henney (kevlin_at_[hidden])
Date: 2005-01-30 08:34:05

In message <000c01c506b9$fed670b0$0300000a_at_pc>, Terje Slettebø 
<tslettebo_at_[hidden]> writes
>----- Original Message -----
>From: "Preston A. Elder" <prez_at_[hidden]>
>To: <boost_at_[hidden]>
>Sent: Sunday, January 30, 2005 4:56 AM
>Subject: [boost] Re: Complex type failure with boost::lexical_cast
>
>I am of the opinion we should follow the standard (ie. STL) in this one.
>The STL would accept both, and since we rely on operator>>, so should we.

Technically, the _STL_ doesn't do anything about spaces because it 
doesn't do anything with I/O ;-) However, given that I/O streams handle 
spaces inconsistently wrt what we think of as the representation of a 
type, it does not seem the best example to follow -- people prefer 
something that works consistently.

>I mean, if you're going to be anal about spaces, be completely anal about
>them, but I don't think we should be, I think accepting whitespace before
>and after is correct, just as the stringstream operator>> does by default.

And that is where the problems begin. The older versions of lexical_cast 
had problems because they behaved like the other types that work with 
I/O streams... but since the other types don't work consistently or 
sensibly with I/O streams, this causes problems. For example, if we do 
as the standard does, then lexical_cast will not work when reading a 
single whitespace character and it will pick out the first 
space-separated sequence from a string. It is unlikely anyone would 
consider this desirable.

So, if you're going to deal with spaces, deal with them consistently and 
avoid surprises. And over time this is what lexical_cast has been 
converging on. This latest bug is one that will be fixed, continuing the 
trend towards total consumption of the input representation -- we 
thought we had it, but this corner case was missed and fixing it will 
improve coverage. Reverting to inconsistent behaviour is not an 
attractive option.

Hope that clarifies the rationale!

Kevlin
-- 
____________________________________________________________
   Kevlin Henney                   phone:  [phone]
   mailto:kevlin_at_[hidden]     mobile: [phone]
   http://www.curbralan.com        fax:    [phone]
   Curbralan: Consultancy + Training + Development + Review
____________________________________________________________