41–49 of 49 posts
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:
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 :(
since the underlying storage is std::array, 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.
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: https://www.rfc-editor.org/rfc/rfc1014
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?
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.
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++.
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/ )