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.

Thanks again for this comment. Consider Cereal copied, now only a single function is required.

Thanks. The documentation could definitely be fleshed out with some more examples.

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.

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.

On the plus side, it's optional. The same thing can be achieved with put()/get() equivalents.

>operator overload abuse

Array programming languages smugly enter the chat

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<T> && std::is_trivial_v<T>;

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.

Because the only way to do metaprogramming in C++ is via the type system. Thismakes it so you need to implement 'functions' as types.

Practically, it's all through this `type_traits` header that (often) end up in unreadable messes. It's all possible because of the catchy acronym SFINAE. It doesn't make much sense to me either, so I avoid it :)

https://en.cppreference.com/w/cpp/language/sfinae

I'm biased but in my experience, no, not at all.

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.

Thanks for the interesting link. :)

Thanks very much. :)

Agreed but just to clarify, Hexi sits at a level below something like MessagePack because it doesn't impose any particular encoding on you since the use-case was handling arbitrary binary protocols that you might not have any control over. You could build support for MessagePack on top of Hexi but not the other way around. They're all very different use-cases.

.h is the more common convention even in the C++ world.

Correct but it doesn't claim to be zero-copy overall. Apologies if it was misleading. In the README, zero-copy is mentioned in context of using view() and span() to obtain views into the buffer, which does allow for it. Very much a "there be dragons but if you're sure..." feature but it's there as an option.

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.

Thanks, that was the hope! :)

I would have liked a different froggy reaction for each section but the project budget was zero. :^)

The problem is that without image captions or subtitles, you lose accessibility for anyone with a screen reader.