std::cout deal with uint8_t as a character

Question

If I run this code:

std::cout << static_cast<uint8_t>(65);

It will output:

A

Which is the ASCII equivalent of the number 65. This is because uint8_t is simply defined as:

typedef unsigned char uint8_t;

• Is this behavior a standard?

• Should not be a better way to define uint8_t that guaranteed to be dealt with as a number not a character?

I can not understand the logic that if I want to print the value of a uint8_t variable, it will be printed as a character.

P.S. I am using MSVS 2013.

Answer 1

Is this behavior a standard

The behavior is standard in that if uint8_t is a typedef of unsigned char then it will always print a character as std::ostream has an overload for unsigned char and prints out the contents of the variable as a character.

Should not be a better way to define uint8_t that guaranteed to be dealt with as a number not a character?

In order to do this the C++ committee would have had to introduce a new fundamental type. Currently the only types that has a sizeof() that is equal to 1 is char, signed char, and unsigned char. It is possible they could use a bool but bool does not have to have a size of 1 and then you are still in the same boat since

int main()
{
    bool foo = 42;
    std::cout << foo << '\n';
}

will print 1, not 42 as any non zero is true and true is printed as 1 but default.

I'm not saying it can't be done but it is a lot of work for something that can be handled with a cast or a function

---

C++17 introduces std::byte which is defined as enum class byte : unsigned char {};. So it will be one byte wide but it is not a character type. Unfortunately, since it is an enum class it comes with it's own limitations. The bit-wise operators have been defined for it but there is no built in stream operators for it so you would need to define your own to input and output it. That means you are still converting it but at least you wont conflict with the built in operators for unsigned char. That gives you something like

std::ostream& operator <<(std::ostream& os, std::byte b)
{
    return os << std::to_integer<unsigned int>(b);
}

std::istream& operator <<(std::istream& is, std::byte& b)
{
    unsigned int temp;
    is >> temp;
    b = std::byte{b};
    return is;
}

int main()
{
    std::byte foo{10};
    std::cout << foo;
}

Answer 2

It's indirectly standard behavior, because ostream has an overload for unsigned char and unsigned char is a typedef for same type uint8_t in your system.

§27.7.3.1 [output.streams.ostream] gives:

template<class traits>
basic_ostream<char,traits>& operator<<(basic_ostream<char,traits>&, unsigned char);

I couldn't find anywhere in the standard that explicitly stated that uint8_t and unsigned char had to be the same, though. It's just that it's reasonable that they both occupy 1 byte in nearly all implementations.

 std::cout << std::boolalpha << std::is_same<uint8_t, unsigned char>::value << std::endl; // prints true

To get the value to print as an integer, you need a type that is not unsigned char (or one of the other character overloads). Probably a simple cast to uint16_t is adequate, because the standard doesn't list an overload for it:

uint8_t a = 65;
std::cout << static_cast<uint16_t>(a) << std::endl; // prints 65

Demo

Answer 3

Posting an answer as there is some misinformation in comments.

The uint8_t may or may not be a typedef for char or unsigned char. It is also possible for it to be an extended integer type (and so, not a character type).

Compilers may offer other integer types besides the minimum set required by the standard (short, int, long, etc). For example some compilers offer a 128-bit integer type.

This would not "conflict with C" either, since C and C++ both allow for extended integer types.

So, your code has to allow for both possibilities. The suggestion in comments of using unary + would work.

Personally I think it would make more sense if the standard required uint8_t to not be a character type, as the behaviour you have noticed is unintuitive.