Boost logo

Boost :

From: Kevlin Henney (kevlin_at_[hidden])
Date: 2001-07-26 10:21:18

> From: Kostya Altukhov <kostya_at_[hidden]>
>I recently discovered even more surprising behavior of
>lexical_cast (at least on VC++6sp4):
>// ...
>int i = 12345;
>string s = lexical_cast<string>(i); // this will succeed
>double d = lexical_cast<double>(s); // this will throw
>I am kinda cautious about using lexical_cast after that,
>especially when not in "C" locale...

This is almost but not quite the right conclusion.

The only reason lexical_cast is broken using locales under VC is because
locale support under VC is broken. The appropriate conclusion is not to
be suspicious of lexical_cast when using locales, but to be suspicious
of using locales >:->

I am not an internationalisation or C++ locales expert, but I can tell
you that a locale implementation is off to a bad start when it uses only
language (specified in English :-}) to specify locale. As its name
suggests, a locale is also sensitive to location, eg US English vs
British English or Canadian French vs French French.

I believe that the num_get is failing to account for thousands
separators, which means that "german" (and "italian", "danish",
"icaelandic", "spanish", "portuguese", etc) will fail because they write
out "12.345" and fail to parse the "." on the way back in. Also,
"english" fails because the "," is not handled correctly. Interestingly,
"french", "finnish", "swedish" and "norwegian" (and possibly others) do
not fail, but give completely the wrong result nonetheless: they write
out "12" and read it back successfully (a '\0' problem in num_put?). As
for most other languages ("greek", "polish", "russian", "welsh", etc)
you can forget it: they are not supported and crash the system -- oops,
I mean they result in undefined behaviour ;-)


  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