On 5/9/07, Alexander Nasonov <alnsn@yandex.ru> 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 +63 928 7291459