Consider copying Cereal, which solves this problem by requiring you to create a single templated function ( https://uscilab.github.io/cereal/ )
#include <print>
#include <type_traits>
namespace hexi {
struct streamer { };
template<typename T>
void operator<<(streamer& s, const T& e) {
if constexpr(std::is_integral_v<T>) {
std::println("number: {}", e);
} else if constexpr(std::is_aggregate_v<T>) {
auto& [...mems] = e;
(std::println("member: {}", mems), ...);
}
}
}
struct user_type {
int x;
std::string y;
};
int main() {
hexi::streamer s;
s << 123;
s << user_type{.x = 456, .y = "foo"};
}
I'd like to read an even more thorough overview of how it works and all the gotchas before I'd consider using this 'in production' but the API looks very easy to use and very elegant.
EDIT: just hit the section on portability, seems like you would always have to use that API, yeah? I feel like when you are writing network code you simply have to make it portable from the get-go. I guess I'm always thinking about having it run on client machines.
You'd likely want to always use that API (or layer something on top of it) unless you're in control of both ends and know they were built with the same toolchain & settings. One area where I've skipped over it is by writing a basic code gen tool (albeit unfinished as most personal projects) that generates the serialisation functions at compile-time from a very basic DSL that describes the network structures (of a game protocol I don't control). If it detects that the current toolchain is going to generate a binary-compatible struct layout and there aren't any variable length fields in there (no strings, basically), it'll generate a memcpy (via using get/put on the stream) rather than per-field (de)serialisation. If it can guarantee alignment of the buffer, which is a tougher requirement to meet, it'll give you a view directly into the network buffer so you effectively have zero-overhead deserialisation. Very much a work in progress but there's scope for making things quite efficient with just a few basic building blocks.
Bjarne appears to prefer cout though, so it isn't universal.
On US layout colon is a single keypress but < is shift+.
This may explain the discrepancy.
—- from someone who read Bjarne at 16yo. All hail the Bjarne
I tried adding std::string to the UserPacket (from the README)
struct UserPacket {
// uint64_t user_id;
// uint64_t timestamp;
// std::array<uint8_t, 16> ipv6;
std::string test;
};
Basically, if it seems like memcpying the structure might be a reasonable thing to do, it'll work. This is why types like std::array will work but std::vector and std::string won't. It can handle those types when inserted individually but not in aggregate since there's no reflection.
The compiler barf does tell the user why it was rejected but... average C++ errors, even with concepts. Not the greatest.
main.cpp:136:52: note: the expression ‘is_trivial_v [with T = UserPacket]’ evaluated to ‘false’ 136 | concept pod = std::is_standard_layout_v<T> && std::is_trivial_v<T>;
https://github.com/eliasdaler/MetaStuff
Another take on the same idea with even simpler interface:
> What does that mean
Have you ever noticed that the (compile time) "rules" for interacting with templated functions are somewhat different from those of non-templated functions? I don't know if "functions as types" is entirely fair but there is definitely some weirdness.
It can generate efficient JS and C++ from a simple YAML file.
I don't use the amalgamated version, though (that only exists for this standalone version) and the library overall is significantly smaller than either of those and doesn't drag in nearly as many standard library headers.
It’s far better than the other binary serialization protocols I’ve looked at / implemented. NFSv3 uses it, and it is compatible with a lot of the tricks you play, like in-place endian translation, branch avoidance, zero allocation use cases, etc:
But soon you’ll be bitten by the fact you don’t have a schema and so you’ll move to something like Protobuf or the more efficient FlatBuffers
UserPacket packet;
stream >> packet;
I've also built some tooling on top that makes use of those functions to do zero-copy deserialisation where viable, so it is possible in the right scenarios with a bit of work but it definitely isn't going to always fit.
since the underlying storage is std::array<char, ...>, it's alignment may be less that the required alignment of the requested type and that of the pointers being stored in the free list.
I would have liked a different froggy reaction for each section but the project budget was zero. :^)