5 ms·
The compiler can optimize this. See https://gcc.godbolt.org/z/hxW7hhrd7 https://gcc.godbolt.org/z/hxW7hhrd7 #include <cstdint> uint32_t read_le_uint32(cons
by neonz80 2y ago
The compiler can optimize this. See https://gcc.godbolt.org/z/hxW7hhrd7 https://gcc.godbolt.org/z/hxW7hhrd7
#include <cstdint>
uint32_t read_le_uint32(const uint8_t* p)
{
return p[0] | (p[1] << 8) | (p[2] << 16) | (p[3] << 24);
}
ends up as
read_le_uint32(unsigned char const*):
mov eax, dword ptr [rdi]
ret
This works with Clang and gcc on x86_64 (but not with MSVC).
- iscoelho 2y agoThe purpose of zero-copy can be to avoid deserialization at all. All you do to deserialize is: uint8_t *buf = ...; struct example_payload *payload = (struct example_payload *) buf; That's why when you access the variables you need to byte order swap. This is absolutely not portable, I agree. I also agree that it is error-prone. However, it is the reality of a lot of performance critical software.
- plorkyeran 2y agoYeah, I’ve occasionally had to manually special case big/little endian code, but most of the time you can write the generic code and the optimizer will take care of it. Unless you’re doing something very complicated it’s a quite trivial optimization to perform.