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

In message <000c01c506b9$fed670b0$0300000a@pc>, Terje Slettebø <tslettebo@broadpark.no> writes
----- Original Message ----- From: "Preston A. Elder" <prez@neuromancy.net> To: <boost@lists.boost.org> 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: +44 117 942 2990 mailto:kevlin@curbralan.com mobile: +44 7801 073 508 http://www.curbralan.com fax: +44 870 052 2289 Curbralan: Consultancy + Training + Development + Review ____________________________________________________________

Kevlin Henney wrote:
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.
This still does not answer the real question. If I write something like istream& operator>>(istream& is, my_class& c) { return is >> c.a >> c.b; } then lexical_cast to 'my_class' won't work. Do you think it's the problem with lexical_cast, or with the above code? - Volodya
participants (2)
-
Kevlin Henney
-
Vladimir Prus