Wow that api looks fantastic! Bravo!
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.
I know it's a convention since the inception of the language, but the operator overload abuse of the bitshift operator still makes me sad every time I see it :(
What are the exact constraints on the struct contents, i.e. what is it that your library can't serialize?
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;
};
In the same vein, but without needing to create separate de- and serialize functions:
https://github.com/eliasdaler/MetaStuff
Another take on the same idea with even simpler interface:
By the way I looked through the code, and had to read about metaprogramming in C++. I wonder why is it so complicated? For example, why constraints like std::is_integral are represented by structs. Doesn't make much sense to me. A function wouldn't be better here?
Fun! It reminds me of my own attempt at this: https://github.com/louisabraham/ubuf
It can generate efficient JS and C++ from a simple YAML file.
These days, whenever i read "headet only" i immediately get scared about compile times. Does using this library make compilation expensive in the way that eg protobuf or nlohmann_json do?
This looks very cool. Based on the examples, you might like XDR.
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:
It's been a while since I saw a new library with such a clean interface. Congrats!
If you need schema-less serialiation there’s MessagePack.
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
Why .h for a CPP library and not .hpp? Threw me off as I usually expect .h to be associated with C files, opening it I find modern C++.
It doesn't look like zero-copy though in this example:
UserPacket packet;
stream >> packet;
incidentally, the block allocator implementation fails to properly account for alignment requirements:
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.
Damn, the frog reminded me to unload my dishwasher which I really have to do
Lovely API, great work on that.
Semi off-topic, but I just love the header image and the advice frog in the readme. Makes reading the documentation more fun and enjoyable.
[dead]
[dead]
Your lib requires manually creating both a serializing and deserializing function. If the functions are out of sync, bad things happen.
Consider copying Cereal, which solves this problem by requiring you to create a single templated function ( https://uscilab.github.io/cereal/ )