Re: [boost] [HEAD] lexical_cast<int8_t>("127") bug?

From: Dean Michael Berris (mikhailberis_at_[hidden])
Date: 2007-05-09 14:56:58

On 5/9/07, Alexander Nasonov <alnsn_at_[hidden]> wrote:
>
> I'd like to remind that boost doesn't have a sole control on
> lexical_cast anymore, see N1973
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1973.html
>
> There is a good sentence in the document:
>
> "We are not in a position to change I/O streams at this late stage, but
> something like lexical_cast is not required to repeat those little
> surprises."
>

Which makes sense for lexical_cast to be able to do the "right thing"
as the semantics of usage imply, even if it's just the one that Boost
implements. Watchathink?

> Though, I completely agree with Gregory.
>
> What do you folks think of this change in the documentation?
>
> FAQ
>
> Q: Why lexical_cast<int8_t>("127") throws bad_lexical_cast?
> A: The type int8_t is a typedef to signed char which is read
> from a stream that holds "127". The bad_lexical_cast is thrown
> because the stream is not at EOF after reading. The standard
> defines same semantics for all char types. Possible workaround
>
> numeric_cast<int8_t>(lexical_cast<int>("127"))
>
> or, more generic expression for any integer type T
>
> numeric_cast<T>(lexical_cast< promote<T>::type >("127"))
>

I have no objections.

That is granted if we really don't want to make
lexical_cast<int8_t>("127") "just work" as how the semantics of usage
actually imply.

I'd be alright with just a documentation of the possible pit-fall. But
I'd still rather be able to "code what I mean" when
lexical_cast<int8_t>(some_string) is needed in my code.

Guess I'd have to work on a patch that does break existing functionality then...

Thanks for the responses! :)

-- 
Dean Michael C. Berris
http://cplusplus-soup.blogspot.com/
mikhailberis AT gmail DOT com
[phone]