3 ms·
Endianness problems should have been solved by compilers, not by programmers. Most existing CPUs, have instructions to load and store memory data of various si
by adrian_b 7mo ago
Endianness problems should have been solved by compilers, not by programmers.
Most existing CPUs, have instructions to load and store memory data of various sizes into registers, while reversing the byte order.
So programs that work with big-endian data typically differ from those working with little-endian data just by replacing the load and store instructions.
Therefore you should have types like int16, int32, int64, int16_be, int32_be, int64_be, for little-endian integers and big-endian integers and the compiler should generate the appropriate code.
At least in the languages with user-defined data types and overloadable operators and functions, like C++, you can define these yourself, when the language does not provide them, instead of using ugly workarounds like htonl and the like, which can be very inefficient if the compiler is not clever enough to optimize them away.
- wakawaka28 7mo agoIf two machines have different endianness, then there is no optimal byte order for either one. Therefore, this problem can't be solved in a one-size-fits-all optimal solution. People have tried to make code generators to take some of the pain out of encoding/decoding but that isn't effortless either.
- cbarrick 7mo agoDefining BE integer data types seems like a bad approach. I wouldn't want to maintain those types. The maintainer would either have to implement all of the arithmetic operations or assume that your users would try to hack their way to arithmetic. But really, you shouldn't ever do arithmetic with non-native endianness anyway. Instead, define all your interfaces to work with native endianness integers and just do byte swapping at the serialization boundaries.