Boost C++ Libraries: Ticket #6571: lexical_case(someString) does not recognize IEEE exceptions

summary changed

Fri, 17 Feb 2012 16:37:21 GMT

summary lexical_case<double>(someString) does not recognize IEEE exceptions → lexical_case<float>(someString) does not recognize IEEE exceptions

status changed

Antony Polukhin — Sat, 18 Feb 2012 08:52:26 GMT

status new → assigned

I`ve tested on GCC compiler, and

boost::lexical_cast<string>(sqrt(-1.0));

returns "-nan", which is correct according to standard.

Please, tell me about the compiler you are using.

Sat, 18 Feb 2012 10:22:35 GMT

As my comments in the example code show, converting to string or char* is always OK. Problem arises when you want to convert the string representation of the error into a floating point type (say, double). For example trying to lexical_cast the above result ("-nan" in GCC, "-1.#IND" in MSVC) to a double throws bad_lexical_cast instead of returning a double containing that special value.

Antony Polukhin — Mon, 20 Feb 2012 16:37:17 GMT

I`ve tested boost_1.48 on VC10 and boost::lexical_cast<string>(sqrt(-1.0)); output is '-nan'.

"-1.#IND" is not a standard, but rather a compiler specific extension. Lexical_cast will not support it.

You can use lexical_cast everywhere and have a cross platform portable behavior. Or you can wrap around lexical_cast function and use that wrapper to support compiler extensions, violating standard.

Thu, 23 Feb 2012 20:28:14 GMT

I'm not specifically speaking about -1.#IND. lexical_cast fails to convert -nan and inf from a string type to their floating point values too.

If lexical_cast is able to successfully convert the double undefined value to its string representation (-1.#IND, -nan, etc) then it must also be able to do the vice versa without throwing errors, No?

If you're wondering why it makes sense to implement such a conversion: I'm working on a program that frequently reads/writes double's to/from file. In the program calculations, sometimes undefined or infinity values are generated (which are fine and sometimes necessary in the program's logic). Now I have no problem saving them to disk (since lexical_cast<string>(someUndefinedDouble) works) but can't read them back (since e.g lexical_cast<double>("-nan") fails).

Antony Polukhin — Fri, 24 Feb 2012 04:03:42 GMT

Lets start from the beginning:
1) I`ve tested lexical_cast<double>("-nan") on VC10 and it passed
2) I`ve tested boost::lexical_cast<string>(sqrt(-1.0)); on VC10 and it passed and outputteed "-nan"
3) There are about 90 tests on nan/inf and they pass: tests, results1, results2. And they are passing since boost_1.48

I can not reproduce your error, so please can you answer the following questions:
1) Which version of boost are you using exactly? Is it boost_1.47, is it boost_1.48?
2) Which compiler exactly are you using? Is it Visual Studio 2010, is it Visual Studio 2003?
3) Reproduce the error on your compilerand copypaste the code that produces error to this ticket.

Fri, 24 Feb 2012 10:23:10 GMT

Oops, it seems I mixed up boost versions.

My boost on Windows was 1.47 which is why boost::lexical_cast<string>(sqrt(-1.0)) returned -1.#IND on Visual Studio (it's 2010 btw). On 1.48 it returns -nan and can be converted back to double.
So a major part of this bug report doesn't make sense now. Sorry about the mistake here. :(

However, the title question still makes sense about -1.#IND. Neither nan nor -1.#IND are global standards. -nan is the standard on *nix (and GCC on windows), but all Microsoft compilers (since VS5 and even before that I guess) represent the error value as -1.#IND, 1.#QNAN, etc. (Simply try cout << sqrt(-1.0)). So I think it's essential to implement such a conversion: boost::lexical_cast<double>("-1.#IND") to work. Since with a Microsoft compiler one might occasionally encounter the -1.#IND and other error strings generated by conversion methods other than boost::lexical_cast or from external libraries.

I also found this: http://en.wikipedia.org/wiki/NaN#Display.

Antony Polukhin — Sun, 26 Feb 2012 09:15:54 GMT

There is a formal specification for Not-A-Number strings in C. According to standard strtod, strtof, and strtold, scanf, sscanf and fscanf functions must parse NaN like that:

The expected form of the subject sequence is an optional plus or minus sign, then one of
the following:
— INF or INFINITY, ignoring case
— NAN or NAN(n-char-sequenceopt), ignoring case in the NAN part, where:
...

C++ stream operators use those functions for conversion.

I`ll add your questions to the lexical_cast documentation (FAQ section).

status, version changed; resolution set

Antony Polukhin — Sun, 26 Feb 2012 09:25:48 GMT

status assigned → closed
version Boost 1.48.0 → Boost 1.50.0
resolution → fixed

Documentation updated in r77118.