From: Dean Michael Berris (mikhailberis_at_[hidden])
Date: 2007-05-08 01:39:37
On 5/7/07, Phil Endecott <spam_from_boost_dev_at_[hidden]> wrote:
> You haven't said what you expected to happen and what happened
> instead. So here's a guess: you expect int8_t to be treated as an
> integer by lexical_cast. It isn't; despite the name, it's a character;
> you are asking it to convert a string to a character. (Try some other
> strings where you have "127". I think it will reject anything with
> more than one character in it.)
Yup, your guess is right.
> I have previously suggested that this behaviour should change, but the
> opinion of the list has been that using int8_t probably indicates
> "over-optimised code", and that the feature can be easily worked around
> with some additional casts.
> In this case, I suggest that you lexical_cast to int, do a bounds check
> yourself (if necessary) and then assign to the int8_t.
Although I would agree with the observation that the code would be
"over-optimised" where int8_t would appear, I still think the
semantics of `lexical_cast<int8_t>("127")` should allow for the
conversion to happen -- either convert to a 'short int' then assign to
a char, if that makes any sense.
I agree that it should be changed, either maybe with a compile-time
assertion saying that "lexical_cast<char> is undefined", or making it
"just work" as the semantic suggests.
At the very least, we should document this to say that 'int8_t is not
really an int, therefore lexical_cast won't work correctly with it'.
-- 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