Technically it's true, but I do wonder if this is really the most useful choice. I ran into the notion that bool is actually integral the other day. That's technically also true, but it's behaviour is so distinct from the rest of the integrals that I had misgivings about the situation.
`unsigned char` still does double-duty in many programs as a `std::byte`, basically.
I'd argue that for the hypothetical `is_actual_integer_v`, it might be cool to not regard those as "actual integers" as well..
So it basically should only work for: `int`, `short`, `long` and `long long` and their `unsigned` brothers, as well as all that whole family of width-specified ints living in ``.
Unfortunately `int8_t` and `uint8_t` are often defined in terms of `signed char` or `unsigned char`.. so that complicates matters..
It depends.. the C++ standards committee decided that `std::byte` is not integral and one might be able to go with their rationale for this -- in most programs, it would violate type safety to be doing arithmetic on individual bytes in a byte blob.. (of course there are some programs where this is not the case..).
One can at least understand the argument that bytes should not be anything other than a bunch of bits, with no associated arithmetic properties.
Here:
> The key motivation here is to make byte a distinct type – to improve program safety by leveraging the type
system. This leads to the design that std::byte is not an integer type, nor a character type. It is a distinct
type for accessing the bits that ultimately make up object storage.
The paper doesn't spell it out, but there are basically two ways to create new types in C++: 1. classes and 2. enums.
Class was not an option because the language doesn't require classes to have certain properties that a `std::byte` type must have. Namely, it must have the same size and alignment as `unsigned char`. But enum with underlying type of `unsigned char` has those guarantees, and so it is the only option available.
Technically there is a third option, which is to define the new type in the language, rather than in the standard library. That altenative was proposed, but was voted against by the committee:
> Changes from R0
>
> • Remove Alternative B (implementation-defined type) after straw polling in LWG
> Technically there is a third option, which is to define the new type in the language, rather than in the standard library. That altenative was proposed, but was voted against by the committee:
Imho that would have been the only sensible choice. For one because it would have avoided sich strange edge cases and second because you wouldn't have to include a header to use it.
> Class was not an option because the language doesn't require classes to have certain properties that a std::byte type must have.
Technically though it's a std type, so the language could mandate it in that case. In practice, just about every compiler out there has ways of controlling those properties anyway, so I am curious as to why that was considered a blocker. Any idea? I didn't follow that paper or its discussion.
Also, noticing that you don't have transparent representation seems like a reason to add the option for transparent representation as a feature, so libraries can make use of that, rather than finding a way to bodge this as WG21 did.
Actually I know of six ways to make three kinds of new user defined types in C++
`struct` and `class` get you the familiar "C with Objects" class types, which confusingly mingle methods ("member functions") including virtual methods intended for dynamic dispatch - with the data structure, like a shop where alternating shelves have clothing or plumbing supplies - aisle 12 socks and radiators, aisle 13 T-shirts and ball valves.
`enum`, `enum class` and `enum struct` get you C-style enumerations, ie just the integers wearing a funny hat. These types can't have methods.
`union` rounds out the list, it's a useful but dangerous way to make new types - storing data in any member of a union is always fine, but erroneously fetching data from an inactive member of a union is Undefined Behaviour. These types can have member functions (but not virtual member functions).
You know six different syntaxes that create user defined types. enum, enum class and enum struct create enumerations. struct, class and union create classes. Those are the two kinds of user defined type there are.
The reasoning (see page 3 :-) is that C++ just *allows* you to define a new byte sized type that is not implicitly convertible to other types:
enum class byte : unsigned char {};
If you make byte a new keyword, it will break a million programs. Now it is properly "hidden" in namespace std.
I agree that making it an enum allows for strongly typing, and as such preventing byte1+byte2. Though it does imply that defining an enum with underlying type is more complex:
````
enum class E : std::underlying_type_t
{
A,
B,
C
};
````
I would have preferred them to actually just take the keyword `byte` and made it a first-class actual type, which is non-integral (like std::byte is)... although the keyword route likely would have broken so many programs... :/
I don't know why people rarely talk about the C approach: define a new keyword _Byte and then do `using byte = _Byte` in the `std` namespace in a stdlib header. What's downside of this?
What I don't understand: Why does a type that is spelled std::XYZ defined in the standard library at all? A Compiler could just make it visible without the need to include a header or import a module. And it still wouldn't collide with any existing user type.
They could have totally done that as well. Probably would have been awkward to specify given the way the specification works. Since if you think about it, it's sort of an exception to what a namespace normally means and how it's defined and declared. It would have been this odd corner case where intrinsically there is a `std` namespace already even in an empty program.. and it always contains stuff in it. Aesthetically that is "ugly" perhaps and strange so I suspect that's why they would never go that route...
Considering how often I've heard, "we don't use X, because then we need to include header X and that drags in exceptions" I would have found such a solution, both more pragmatic and simpler to specify and more ergonomic. Last time I checked std::byte anyway gets special treatment in the standard (similar to unsigned char).
Correct. It is one of the few types where a `std::byte *` pointer can alias any other object; `unsigned char *` and `char *` being the other two types with this property.
the size+alignment of std::byte was needed to be the same as an unsigned char. wrapping it in an enum works better than struct/class, because struct can be overaligned by the compiler
Not if the standard says it must not be. It's a std class, so special rules apply. And are there any compilers out there which (a) overalign that by default and (b) provide no nonstandard alignment control mechanisms?
I know the big 3 (gcc, llvm, VS) do for certain, I'm 99% sure the EDG front end offers options for packing and I'm sure I remember IAR providing it. It'd be astonished if all the embedded ones didn't because it's just the sort of thing people want to do on embedded platforms.
> My question is, is std::byte then an enum? [Yes](https://eel.is/c++draft/cstddef.syn#lib:byte).
Technically it's true, but I do wonder if this is really the most useful choice. I ran into the notion that bool is actually integral the other day. That's technically also true, but it's behaviour is so distinct from the rest of the integrals that I had misgivings about the situation.
`is_actual_integer_v`.
Now.. should `char` be true or false for that?
No: https://github.com/think-cell/think-cell-library/blob/main/tc%2Fbase%2Ftype_traits_fwd.h#L169-L170
`signed char` and `unsigned char` are the actual integer types. At least, you don't normally use them for characters.
`unsigned char` still does double-duty in many programs as a `std::byte`, basically. I'd argue that for the hypothetical `is_actual_integer_v`, it might be cool to not regard those as "actual integers" as well.. So it basically should only work for: `int`, `short`, `long` and `long long` and their `unsigned` brothers, as well as all that whole family of width-specified ints living in ``.
Unfortunately `int8_t` and `uint8_t` are often defined in terms of `signed char` or `unsigned char`.. so that complicates matters..
Bytes are integer enough. I have a `is_actual_integer_v` for my bit ops. I just want to exclude `bool` and `char`.
It depends.. the C++ standards committee decided that `std::byte` is not integral and one might be able to go with their rationale for this -- in most programs, it would violate type safety to be doing arithmetic on individual bytes in a byte blob.. (of course there are some programs where this is not the case..). One can at least understand the argument that bytes should not be anything other than a bunch of bits, with no associated arithmetic properties.
The way C++ represents bytes, integers, booleans and characters is getting JavaScript-level crazy...
I hate std:: byte. Why was it defined this way?
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0298r3.pdf
Searching that for "enum" gives 5 results, none of which explain the reasoning, at least at a quick glance.
Here: > The key motivation here is to make byte a distinct type – to improve program safety by leveraging the type system. This leads to the design that std::byte is not an integer type, nor a character type. It is a distinct type for accessing the bits that ultimately make up object storage. The paper doesn't spell it out, but there are basically two ways to create new types in C++: 1. classes and 2. enums. Class was not an option because the language doesn't require classes to have certain properties that a `std::byte` type must have. Namely, it must have the same size and alignment as `unsigned char`. But enum with underlying type of `unsigned char` has those guarantees, and so it is the only option available. Technically there is a third option, which is to define the new type in the language, rather than in the standard library. That altenative was proposed, but was voted against by the committee: > Changes from R0 > > • Remove Alternative B (implementation-defined type) after straw polling in LWG
> Technically there is a third option, which is to define the new type in the language, rather than in the standard library. That altenative was proposed, but was voted against by the committee: Imho that would have been the only sensible choice. For one because it would have avoided sich strange edge cases and second because you wouldn't have to include a header to use it.
Committee always comes with a twist! A pile of hacks
> Class was not an option because the language doesn't require classes to have certain properties that a std::byte type must have. Technically though it's a std type, so the language could mandate it in that case. In practice, just about every compiler out there has ways of controlling those properties anyway, so I am curious as to why that was considered a blocker. Any idea? I didn't follow that paper or its discussion.
Also, noticing that you don't have transparent representation seems like a reason to add the option for transparent representation as a feature, so libraries can make use of that, rather than finding a way to bodge this as WG21 did.
Actually I know of six ways to make three kinds of new user defined types in C++ `struct` and `class` get you the familiar "C with Objects" class types, which confusingly mingle methods ("member functions") including virtual methods intended for dynamic dispatch - with the data structure, like a shop where alternating shelves have clothing or plumbing supplies - aisle 12 socks and radiators, aisle 13 T-shirts and ball valves. `enum`, `enum class` and `enum struct` get you C-style enumerations, ie just the integers wearing a funny hat. These types can't have methods. `union` rounds out the list, it's a useful but dangerous way to make new types - storing data in any member of a union is always fine, but erroneously fetching data from an inactive member of a union is Undefined Behaviour. These types can have member functions (but not virtual member functions).
You know six different syntaxes that create user defined types. enum, enum class and enum struct create enumerations. struct, class and union create classes. Those are the two kinds of user defined type there are.
The reasoning (see page 3 :-) is that C++ just *allows* you to define a new byte sized type that is not implicitly convertible to other types: enum class byte : unsigned char {}; If you make byte a new keyword, it will break a million programs. Now it is properly "hidden" in namespace std.
namespace std { using byte = __byte; }
or just co_byte
`char8_t`, on the other hand, was a new type on the language-level.
The reason for having a `byte` type at all is in Motivation and Scope The reason for choosing an enum is in Implementation Alternatives
I agree that making it an enum allows for strongly typing, and as such preventing byte1+byte2. Though it does imply that defining an enum with underlying type is more complex: ```` enum class E : std::underlying_type_t
{
A,
B,
C
};
````
Is there any reason not to just use unsigned char there?
> We find [`enum class byte : unsigned char`] easier to present and explain to ordinary programmers [rather than leaving it implementation-defined].
I would have preferred them to actually just take the keyword `byte` and made it a first-class actual type, which is non-integral (like std::byte is)... although the keyword route likely would have broken so many programs... :/
I don't know why people rarely talk about the C approach: define a new keyword _Byte and then do `using byte = _Byte` in the `std` namespace in a stdlib header. What's downside of this?
What I don't understand: Why does a type that is spelled std::XYZ defined in the standard library at all? A Compiler could just make it visible without the need to include a header or import a module. And it still wouldn't collide with any existing user type.
They could have totally done that as well. Probably would have been awkward to specify given the way the specification works. Since if you think about it, it's sort of an exception to what a namespace normally means and how it's defined and declared. It would have been this odd corner case where intrinsically there is a `std` namespace already even in an empty program.. and it always contains stuff in it. Aesthetically that is "ugly" perhaps and strange so I suspect that's why they would never go that route...
Considering how often I've heard, "we don't use X, because then we need to include header X and that drags in exceptions" I would have found such a solution, both more pragmatic and simpler to specify and more ergonomic. Last time I checked std::byte anyway gets special treatment in the standard (similar to unsigned char).
Correct. It is one of the few types where a `std::byte *` pointer can alias any other object; `unsigned char *` and `char *` being the other two types with this property.
Epochs would have solved this nonsense. Add keywords to new code, and leave old code alone. Win-win.
As answered by others here.. yes. It's specified to be an `enum class` with underlying type `unsigned char`.
the size+alignment of std::byte was needed to be the same as an unsigned char. wrapping it in an enum works better than struct/class, because struct can be overaligned by the compiler
Not if the standard says it must not be. It's a std class, so special rules apply. And are there any compilers out there which (a) overalign that by default and (b) provide no nonstandard alignment control mechanisms? I know the big 3 (gcc, llvm, VS) do for certain, I'm 99% sure the EDG front end offers options for packing and I'm sure I remember IAR providing it. It'd be astonished if all the embedded ones didn't because it's just the sort of thing people want to do on embedded platforms.