Re: a lexical_cast<> bug?

From: Kevlin Henney (kevlin_at_[hidden])
Date: 2001-07-21 12:25:03

>   From: "Corwin Joy" <cjoy_at_[hidden]>
[...]
>It turns out that the lexical_cast to int will throw because the stream
>operator into int stops at the decimal point.  Therefore lexical cast says
>that the int operator did not "succeed" because it did not read the full
>string -- even though it reads the integer part of the string and
>initializes the local result to 123 just fine.  It's a bit of a surprise
>from a user point of view that this fails.  So the question is:
>A.  Is it intended that the class should throw in this case?
>B.  If it is intended / this kind of cast is not allowed it seems to me like
>a strong warning in the docs should be added.

This is intentional behaviour. The original version of lexical_cast that
was submitted truncated at the decimal point and should be considered
buggy :-> Whilst you can read an int as a double or an int, the opposite
is undesirable -- esp as it is by lexical truncation rather than proper
numeric conversion.

You will find that if you want to have the incompleteness behaviour, it
opens up a Pandora's can of worms as regards completeness and expected
behaviour in many (many) corner cases, eg lexical_cast<int>(".1"),
lexical_cast<int>("1.1e-3"), lexical_cast<int>("1e3").

You are correct in stating that this should be highlighted in the docs,
and should be supported by an explicit example. Having read this thread
I have realised that a reference to an experimental feature (the
context) is still in the docs. I thought I had removed references to
this, but evidently not -- apologies.

Kevlin
____________________________________________________________

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