3 ms·
It could be worse. It could be unspecified whether it is signed or not. But surely nobody would design a language like that.
by gpderetta 4y ago
It could be worse. It could be unspecified whether it is signed or not. But surely nobody would design a language like that.
- account42 4y agoWell, technically C and C++ do not have mistery-signed byte types ... because they don't have byte types but char types which may be larger than a single byte. If someone designed a language this way today they would be called a master troll. At least you can require CHAR_BITS == 8 in practice for everything except weird embedded systems - both POSIX and Windows do just that.
- gpderetta 4y agoChar is the byte type in C (and thus C++), both in theory and in practice. The problem it is a very overloaded type: as a char type it is used for strings, as an integral type is used as a small integer, and, as it is blessed with special semantics (strict aliasing and sizeof(char) = 1), it is also the byte type. Technically C++ now does indeed have a blessed byte type (std::type). But it is not an integral type: it support bitwise operations but not artihmetic ops, so signedness doesn't come into the picture.
- account42 4y ago> Char is the byte type in C (and thus C++), both in theory Not an 8-bit byte which is the definition most people think of when talking about bytes and the only one that matters once you need to interact with other systems. > and in practice. Yes. > Technically C++ now does indeed have a blessed byte type (std::type). But it is not an integral type: it support bitwise operations but not artihmetic ops, so signedness doesn't come into the picture. Its signedness does matter for casts to integral types - int(std::byte(255)) == 255 whereas int(char(255)) is implemenation-defined.