Hi Phil! On 5/7/07, Phil Endecott <spam_from_boost_dev@chezphil.org> 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'. Thanks Phil! -- Dean Michael C. Berris http://cplusplus-soup.blogspot.com/ mikhailberis AT gmail DOT com +63 928 7291459