|
Boost : |
From: Stéphane Bronsart (stephane.bronsart_at_[hidden])
Date: 2002-07-05 02:38:30
Hi,
I've send a resume of all the discussion about
lexical_cast and more generaly string/integer difficulties.
to kevlin, like terje Sletteb say to me.
He is the author of lexical_cast.
I suppose now we have to wait a solution/update/explication about all that.
The more "clear"/"safe" will be the solution, the best it is.
I hope you all agree with me.
Thank a lot for all.
Regards.
Stéphane Bronsart.
(sorry for my poor english...)
"Gennaro Prota" <gennaro_prota_at_[hidden]> wrote in message
news:otj9iuo9srv4imnbrn6oopnj8de6qmfqjk_at_4ax.com...
On Thu, 4 Jul 2002 20:16:22 +0200, Terje Slettebø
<tslettebo_at_[hidden]> wrote:
>>From: "Stéphane Bronsart" <stephane.bronsart_at_[hidden]>
>
>> A signed long can hold value from -2147483648 to 2147483647
>>
>> signed long l;
>>
>> 1) l=lexical_cast<signed long>("2147483647"); // Ok l = 2147483647
>> 2) l=lexical_cast<signed long>("2147483648"); // False : no
exception
>> and l = -2147483648
>> 3) l=lexical_cast<signed long>("2147483650"); // OK exception occurs
>> !!!
>>
>> Why case 2 don't throw exception and case 3 yes ?
>> If lexical_cast throw exption with a value 3 unit greater than the limit,
>> why not with a value 1 greater than the limit ?
>
>This must depend on the implementation of the stream operators for "long".
Yes, I've verified that STLport 4.5.3 has this bug. I'll report it to
Boris. Note that, though
http://std.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#23
makes all the issue quite problematic, I don't think the STLport
behaviour is intentional (Why allowing LONG_MAX + 1 and not LONG_MAX +
2 ?)
[ snip... ]
>> The final solution, for me, is a "specialized" conversion
routine/template
>> dedicated to string/integer conversion.
>
>There are already such conversions, in the C library. The rationale for
>lexical_cast is explained in the docs for it. The purpose of lexical_cast
is
>to improve these ways, also to make it more general. If all you need is
>string/integer conversion, there's atoi() and scanf().
The atof, atoi, atol (and atoll) functions never check for
overflows/underflows. Indeed it's better to avoid them if you are not
absolutely sure that the resulting value can be represented, because
the invoke *undefined behavior* otherwise. If you care about errors
you can use the strtol, strtoll, strtoul, and strtoull functions.
> However, these have
>their own issues, particularly scanf(). lexical_cast uses the stream
>operators, which means that it also takes into account the currently set
>locale, something the C functions don't.
Yes :-)
Genny.
_______________________________________________
Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk