Re: [boost] lexical_cast again...

From: Terje Slettebø (tslettebo_at_[hidden])
Date: 2002-07-04 13:16:22

>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".
By the way, one doesn't need to use "signed", as it's signed by default.

>
//--------------------------------------------------------------------------
> --------------------------------------
> User had to know that :
> signed short i = 60000;
> produce a fault value in i.
> This behavior is in the C/C++ documentation
> Thus I'm agree with you that lexical_cast had to clearly explain WHAT it
can
> do...
>
>
//--------------------------------------------------------------------------
> --------------------------------------
> My modified lexical_cast is not optimized you said.
> I'm agree with you, but generaly I prefer a non-optimized solution which
> work (I don't talk about lexical_cast here ) without ambiguity again an
> optimized solution with "limit" case and/or undefined result in some
(rare)
> situation.

Yes, but for this, the combination of lexical_cast and numeric_cast does
this checking. Just like your proposal.

>
//--------------------------------------------------------------------------
> --------------------------------------
> Don't you think it's time now to :
> 1) Review lexical_cast implementation and/or documentation : You are the
> best guy to do that.

lexical_cast is being reviewed right now, by the author, Kevlin Henney
(kevlin_at_[hidden]). He's a little busy this week, but he told me in a
mail that he'd get to it next week.

If you like, you could mail him about this, because he's the one who decides
how lexical_cast will be.

> And/Or
> 2) Provide via boost a "specialized" lexical_cast like feature to perform
> well "numeric to string" ONLY and vice/versa convertion.

Well, the code-example I gave, does this. So even if it isn't in Boost, one
can still use something like that.

> I'm new in the C/C++ worls, but i seems me crazy that a so used operation
is
> not yet fixed in the language (or in a "standard" library).  All the
> programmers around the world had to perform string/integer conversion.  It
> must be possible to perform this task without using a strstream (heavy).
> 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(). 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.

Regards,

Terje