[lexical_cast] cast of int8_t
Hi! In a previous message I asked if lexical_cast could throw boost::numeric::positive_overflow when the parsing is ok but the value too large for the target type. this turned out to be difficult because it breaks existing code, alternatively there could be another exception derived from bad_lexical_cast that indicates the overflow but this seems to be a lot of work. another question is why does lexical_cast treat int8_t and uint8_t like char? technically I see no reason for this as c++ has three types: char, signed char and unsigned char. in my code I use only char for characters and signed/unsigned char as numbers. I know that the standard stream operator << treats signed/unsigned char as char but I know no explanation for this (I consider it a bug ;-) -Jochen
On Sat, Oct 13, 2012 at 10:35 PM, Jochen Wilhelmy <jochen.wilhelmy@googlemail.com> wrote:
another question is why does lexical_cast treat int8_t and uint8_t like char? technically I see no reason for this as c++ has three types: char, signed char and unsigned char.
I might be wrong, but aren't there only two types, signed char and unsigned char, with unqualified char being equivalent to one of them (depending on platform)? -- Olaf
On Sat, Oct 13, 2012 at 11:14:30PM +0200, Olaf van der Spek wrote:
On Sat, Oct 13, 2012 at 10:35 PM, Jochen Wilhelmy <jochen.wilhelmy@googlemail.com> wrote:
another question is why does lexical_cast treat int8_t and uint8_t like char? technically I see no reason for this as c++ has three types: char, signed char and unsigned char.
I might be wrong, but aren't there only two types, signed char and unsigned char, with unqualified char being equivalent to one of them (depending on platform)?
They are three distinct types. The signedness (and thus the range of values it can take on) of plain char is the same as one of the unsigned/signed char, but it's still a distinct type, see C++11 3.9.1/1. -- Lars Viklund | zao@acc.umu.se
On 13/10/12 16:35, Jochen Wilhelmy wrote:
another question is why does lexical_cast treat int8_t and uint8_t like char? technically I see no reason for this as c++ has three types: char, signed char and unsigned char. in my code I use only char for characters and signed/unsigned char as numbers. I know that the standard stream operator << treats signed/unsigned char as char but I know no explanation for this (I consider it a bug ;-)
Whatever we think of the standard streams' decision (and indeed I agree it's dubious), lexical_cast behaves in this way because it is defined in terms of the standard streams. Personally I think that is the right choice. Consistency is more important than tweaking each individual case. John
On 13/10/12 16:35, Jochen Wilhelmy wrote: another question is why does lexical_cast treat int8_t and uint8_t like char? technically I see no reason for this as c++ has three types: char, signed char and unsigned char. in my code I use only char for characters and signed/unsigned char as numbers. I know that the standard stream operator << treats signed/unsigned char as char but I know no explanation for this (I consider it a bug ;-)
Changing the current behavior will break existing user code. However you can always use lexical_cast<std::string>(static_cast<short>(int8_value)) or even make some wrapper: template <class To> To my_cast(unsigned char f) { return boost::lexical_cast<To>(static_cast<int>(f)); } template <class From, class To> To my_cast(const From& f) { return boost::lexical_cast<To>(f); } 2012/10/14 John Bytheway <jbytheway+boost@gmail.com>:
Whatever we think of the standard streams' decision (and indeed I agree it's dubious), lexical_cast behaves in this way because it is defined in terms of the standard streams. Personally I think that is the right choice. Consistency is more important than tweaking each individual case.
Totally agree. -- Best regards, Antony Polukhin
participants (5)
-
Antony Polukhin -
Jochen Wilhelmy -
John Bytheway -
Lars Viklund -
Olaf van der Spek