Boost logo

Boost :

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 Henney phone: +44 117 942 2990
  mailto:kevlin_at_[hidden] mobile: +44 7801 073 508 fax: +44 870 052 2289
  Curbralan: Consultancy + Training + Development + Review

Boost list run by bdawes at, gregod at, cpdaniel at, john at