[dead]
Show HN: Hexi – Modern header-only network binary serialisation for C++
21–30 of 49 posts
Re: Show HN: Hexi – Modern header-only network binary serialisation for C++
#22Semi off-topic, but I just love the header image and the advice frog in the readme. Makes reading the documentation more fun and enjoyable.
The problem is that without image captions or subtitles, you lose accessibility for anyone with a screen reader.
Re: Show HN: Hexi – Modern header-only network binary serialisation for C++
#23I 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 :(
You are not alone. many on the standard committee are trying to get rid of it. std::print is the new way to do io instead of cout in part so you don't have to abuse shift for io. This is new in c++23 though so few people know about it. Bjarne appears to prefer cout though, so it isn't universal.
Danish Bjarne may have his On US layout colon is a single keypress but This may explain the discrepancy.
—- from someone who read Bjarne at 16yo. All hail the Bjarne
Re: Show HN: Hexi – Modern header-only network binary serialisation for C++
#24In 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:
Re: Show HN: Hexi – Modern header-only network binary serialisation for C++
#25Semi off-topic, but I just love the header image and the advice frog in the readme. Makes reading the documentation more fun and enjoyable.
The problem is that without image captions or subtitles, you lose accessibility for anyone with a screen reader.
I made sure to set the alt text for the images for that reason.
Re: Show HN: Hexi – Modern header-only network binary serialisation for C++
#26Your 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/ )
Thanks, that is definitely a downside to the shift operator overloading approach. I'll take that onboard and investigate whether a single operator to handle both would mesh with the current design.
You can just use the boost.pfr technique to iterate fields though.
Or if you want, starting from C++26 and e.g. clang-21: https://gcc.godbolt.org/z/G1TqP3a8P
#include
#include
namespace hexi {
struct streamer { };
template
void operator) {
std::println("number: {}", e);
} else if constexpr(std::is_aggregate_v) {
auto& [...mems] = e;
(std::println("member: {}", mems), ...);
}
}
}
struct user_type {
int x;
std::string y;
};
int main() {
hexi::streamer s;
s Re: Show HN: Hexi – Modern header-only network binary serialisation for C++
#27In 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: https://github.com/apankrat/cpp-serializer
I'll likely add additional functionality for specifying both operations with a single function since it's been mentioned a few times. Thanks for the repos.
Re: Show HN: Hexi – Modern header-only network binary serialisation for C++
#28What 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 ipv6;
std::string test;
};
Re: Show HN: Hexi – Modern header-only network binary serialisation for C++
#29Fun! 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.
Re: Show HN: Hexi – Modern header-only network binary serialisation for C++
#30What 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 ipv6; std::string test; }; and the compilation fails - https://onlinegdb.com/B_RJd5Uws
With more complex structures, you need to specify how it should behave. The definition for 'more complex' here is basically no virtual functions, virtual base classes, is trivially copyable and constructible and a few others.
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 && std::is_trivial_v;