Boost logo

Boost :

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
> 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?
> 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
mikhailberis AT gmail DOT com
+63 928 7291459

Boost list run by bdawes at, gregod at, cpdaniel at, john at