cout of negative value of signed char in C++

Question

How C++ handles cout of negative value of signed char? Is the behavour defined in C++11 standard? I am using MinGW C++ 11 compiler. It looks the signed value is converted to unsigned type by adding 256 and then prints extended ASCII characters.

signed char a=-35;
std::cout<<a;

Answer 1

According to this, the following overload is selected:

template< class Traits >
basic_ostream<char,Traits>& operator<<( basic_ostream<char,Traits>& os,
                                        signed char ch );

And since signed char is not char, a is first converted to a char using widen:

char_type widen( char c ) const;

So your code is equivalent to:

std::cout << std::cout.widen(c);
// or:
std::cout << std::use_facet< std::ctype<char> >(getloc()).widen(c)

As you can see, widen takes a char, so you'll have a conversion from signed char to char prior to the actual "widening".

Even if you are widening from a char to a char, the behavior is implementation-defined — The standard makes no guarantee regarding this.

Answer 2

Use type casting to int...

std::cout << (int)a;

...or, following better C++ programming style (as Christian Hackl suggested):

std::cout << static_cast<int>(a);

This actually does not answer your questions (already been answered by Holt), but shows a solution to the problem.

Answer 3

Most of this is required behavior (and most of what isn't still borders on being required).

To be specific, the C++ standard says that iostreams are associated with C-style input and output streams, so cout is associated with stdout (§[narrow.stream.objects]/3):

The object cout controls output to a stream buffer associated with the object stdout, declared in <cstdio>.

The C standard, in turn, defines narrow-character output as being as-if written via fputc (§7.19.3/12):

The byte output functions write characters to the stream as if by successive calls to the fputc function.

fputc requires (§7.19.7.3/2):

The fputc function writes the character specified by c (converted to an unsigned char) to the output stream pointed to by stream, [...]

So, yes, the conversion to unsigned char is exactly what the standards require. The C standard requires that conversion from signed to unsigned (of any integer type, including char) happen in the following fashion (§6.3.1.3/2):

Otherwise, if the new type is unsigned, the value is converted by repeatedly adding or subtracting one more than the maximum value that can be represented in the new type until the value is in the range of the new type.

So yes, it is converted to unsigned by adding 256 (assuming unsigned char can represent values from 0 to 255, as is typical).

So that leaves us one part that the standard sort of attempts to require, without going quite all the way--the transformation that widen has to do (§[locale.ctype.virtuals]/10):

Applies the simplest reasonable transformation from a char value or sequence of char values to the corresponding charT value or values.

Since it's a little difficult to decide exactly what's "reasonable", this could carry out some more or less arbitrary mapping on your character. In fact, it's apparently mapping input to output without modification (at least for the particular character you're writing), but it's true that other transformations could fall within "reasonable", and it would ultimately be difficult to draw a hard line saying that any particular transformation was not "reasonable".

The other part that's not really required by the C++ (or any other) standard is how something else will interpret that output. All the language standards can mandate is what gets written to the stream. The part with something else opening that stream and interpreting its content as "extended ASCII" (probably one of the ISO 8859 variants) is clearly outside the control of the language (or much of anything else in your program, of course).