Boost logo

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