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.

Donte

Yes it's standards behavior. If you want to use a uint8_t as a small unsigned integer you need to cast it before outputting it. Like e.g. static_cast<uint32_t>(some_uint8_t_variable) – Rajewski

Thanks.. It is not duplicated exactly.. I know why this behaviour is exist. My main two questions were: if this is a standard behaviour and why there is no better way to represent uint8_t as non character type. – Donte

@HumamHelfawi What type could it be? Only char is guaranteed to have a sizeof() of 1. – Weary

@Weary Yes that is exactly my question. Why it could not be a primitive type that has also a size of 1 with another name. – Donte

@HumamHelfawi - there is no primitive type that has a size of 1 and is not a variant of char. Yes, C++ could have added a new type, but that would conflict with C, which is where these typedefs originated. – Henchman

std::cout << +static_cast<uint8_t>(65); will do what you want. – Henchman

As Pete said there is no other type. bool and everything else has an implementation defined size. The only type the exist with a know size of 1 is the char variants. – Weary

@PeteBecker thanks.. is + a unary operator that return some int? because I could not leverage into its declaration within MSVS IDE. It said "there is no overload for + operator" – Donte

+ is a unary operator that acts a lot like the unary -, except that it doesn't negate the value. It's generally viewed as pointless, but it is useful here, because, as an arithmetic operator, the compiler promotes its argument to int. So +x is equivalent to (int)x. – Henchman

@Weary I see. However, as Pete said, it seems a compatibility problem with C. I see that there is no choice rather than char or a totally new type. – Donte

@HumamHelfawi it would be a compiler bug if +static_cast<uint8_t>(65) failed on your compiler – Lutist

@Lutist No it did not.. I just could not see its implementation or declaration (IDE problem not compiler problem) – Donte

Possible duplicate of uint8_t can't be printed with cout – Walters

FWIW, it isn't guaranteed at all that you can even print the uint[_fast|_least]N_t types this way. You have to first cast to unsigned long long, for instance. – Irenics

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;
}

Weary

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

Roomful

They don't have to be the same; uint8_t could be an extended integer type. – Lutist

You wont find anything that actually spells out what the underlying type of uint8_t has to be as uint8_t might not even exist. – Weary

uint16_t might have the same problem , on a system with 16-bit char. (Those are rare though) – Lutist

@M.M: I was trying to convey that they didn't have to be the same, it's just that they are and OP (and everyone else who asks about printing uint8_t) is just unlucky that their implementation chose unsigned char to be a typedef for it, and it probably won't change soon, because it's a reasonable implementation. – Roomful

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.

Lutist

Yes exactly that what I was thinking of. Thanks – Donte

If the standard mandates that it should not be a character type what type should be used? – Weary

@Weary an 8-bit integer type that is not a character type – Lutist