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
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
> 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
> 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
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 +63 928 7291459
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk