2 ms·

1.) Functions are fine for this stuff. The compiler can be trusted for its ability to "inline" the language-level `__builtin_unreachable()` or equivalent at the

1.) Functions are fine for this stuff. The compiler can be trusted for its ability to "inline" the language-level `__builtin_unreachable()` or equivalent at the relevant optimization levels. 2.) static_cast<int> is shorter, if you know that the underlying type is int. But even if you know, you might not want to spell out int, to be more robust to code changes, which might involve a change of the underlying type of the corresponding enum. In generic context you might not even know the underlying type. 3.) I absolutely agree. I think it was a mistake to include. The included `std::byteswap` can be expressed in terms of `std::ranges::reverse(std::as_writable_bytes(obj))`. It could be quality of implementation detail to get a bswap instruction from the latter. I would be happy with equivalents of the `htonl` functions in the standard library, but I have strong opinions of the appropriate function signatures of it for C++.

a2800276 4y ago
> 2.) static_cast<int> is shorter, if you know that the underlying type is int. > But even if you know, you might not want to spell out int, to be more robust to > code changes, which might involve a change of the underlying type of the > corresponding enum. > > In generic context you might not even know the underlying type. Thanks for pointing this out! I'm aware that the underlying type of an enum isn't always `int`. This is what I meant by saying the `static_cast` feels more expressive to me, i.e. reading the code, at least I'll now on sight what type is being used here. I'd probably have to 'let go' more to effectively use CPP, but this category of mechanism to cope with a generic/type system so complicated that I can't figure out the type of anything anymore. In the same vein, 'making code more robust to changes' feels like kicking the can down the road (to me). At some point you'll need to deal with the actual type ...
gpderetta 4y ago
Re 3), all the <bits> instructions can be expressed in high level code, and compilers have been able to convert high level code to the actual machine instructions for a while. The issue is exactly which code pattern is detected by which compiler varies a lot, so to avoid having to rely on that there was a strong push to add all these explicit intrinsics. Also std::bytesewap is more readable than the longer reverse+as_writeable_bytes.
- planede 4y ago
  There is one strong difference between byteswap and other operations within <bit>. byteswap semantically works on the object representation of the integer, while all other operations semantically work on the integer value, expressed in powers of two. The C++ language has no strong requirements on the object representation of the underlying integer. The C++20 guarantee of two's complement also only just expressed in terms of integer value, not bit representation. Therefor `byteswap` somewhat sticks out. It's possibly useful for `std::endian::little == std::endian::native` or `std::endian::big == std::endian::native`, and for `std::has_unique_object_representations_v<T> == true` (aka. no padding bits) for the corresponding integral type T. CHAR_BITS also change the semantics. So, in this sense it is quite low level, and you have to check all of these to make use of it, or you have to implicitly rely on implementation defined values of these for the targets you care about. I'm not saying that byteswap is not useful though. But it has the wrong interface. It reverses sequence of bytes, it does not work on integers. edit: Oh, in addition of having no padding bits, you also want no trap representations. I don't know if you can check for that. edit2: Apparently, you don't necessarily need to check for padding bits, byteswap does it for you, and fails to compile if there are padding bits: https://eel.is/c++draft/bit#byteswap-2 https://eel.is/c++draft/bit#byteswap-2 I don't see trap representations being handled at all. This might be a defect.
  - gpderetta 4y ago
    Thanks, I didn't catch this difference between byteswap and the other <bits> functions.

a2800276 4y ago

> 2.) static_cast<int> is shorter, if you know that the underlying type is int. > But even if you know, you might not want to spell out int, to be more robust to > code changes, which might involve a change of the underlying type of the > corresponding enum. > > In generic context you might not even know the underlying type. Thanks for pointing this out! I'm aware that the underlying type of an enum isn't always `int`. This is what I meant by saying the `static_cast` feels more expressive to me, i.e. reading the code, at least I'll now on sight what type is being used here. I'd probably have to 'let go' more to effectively use CPP, but this category of mechanism to cope with a generic/type system so complicated that I can't figure out the type of anything anymore. In the same vein, 'making code more robust to changes' feels like kicking the can down the road (to me). At some point you'll need to deal with the actual type ...

gpderetta 4y ago

Re 3), all the <bits> instructions can be expressed in high level code, and compilers have been able to convert high level code to the actual machine instructions for a while. The issue is exactly which code pattern is detected by which compiler varies a lot, so to avoid having to rely on that there was a strong push to add all these explicit intrinsics. Also std::bytesewap is more readable than the longer reverse+as_writeable_bytes.

planede 4y ago
There is one strong difference between byteswap and other operations within <bit>. byteswap semantically works on the object representation of the integer, while all other operations semantically work on the integer value, expressed in powers of two. The C++ language has no strong requirements on the object representation of the underlying integer. The C++20 guarantee of two's complement also only just expressed in terms of integer value, not bit representation. Therefor `byteswap` somewhat sticks out. It's possibly useful for `std::endian::little == std::endian::native` or `std::endian::big == std::endian::native`, and for `std::has_unique_object_representations_v<T> == true` (aka. no padding bits) for the corresponding integral type T. CHAR_BITS also change the semantics. So, in this sense it is quite low level, and you have to check all of these to make use of it, or you have to implicitly rely on implementation defined values of these for the targets you care about. I'm not saying that byteswap is not useful though. But it has the wrong interface. It reverses sequence of bytes, it does not work on integers. edit: Oh, in addition of having no padding bits, you also want no trap representations. I don't know if you can check for that. edit2: Apparently, you don't necessarily need to check for padding bits, byteswap does it for you, and fails to compile if there are padding bits: https://eel.is/c++draft/bit#byteswap-2 https://eel.is/c++draft/bit#byteswap-2 I don't see trap representations being handled at all. This might be a defect.
- gpderetta 4y ago
  Thanks, I didn't catch this difference between byteswap and the other <bits> functions.