I’m familiar with capnproto [0], which claims something like zero overhead.

Personally, I just write serialization functions using fwrite/fread/write/read, but I’ve used projects which depend on it.

[0] https://capnproto.org/

I've done that, but it can be very error prone and therefore time consuming.

Instead of relying on serialization of existing data structures I actually try to use more general data structures that already exist in a single span of memory.

Then serialization is just a matter of writing them out from start to finish, or allocating them in a memory mapped file.

Can cereal handle user defined types without having to write custom serialization and deserialization functions for each? At first glance this seems to be the main difference.

Cereal requires a bit more copy & paste template boilerplate (it's a customization point) but they're basically the same.

* libnop uses a macro called NOP_STRUCTURE to create its key-value pairs.

* Cereal has a macro called CEREAL_NVP.

* Boost.Fusion has BOOST_FUSION_ADAPT_ASSOC_STRUCT

* Boost.Hana has BOOST_HANA_ADAPT_STRUCT

* Boost.Serialization has BOOST_SERIALIZATION_NVP

...all these things work the same way to get reflection

Yes! Hopefully C++20 or C++25-ish will provide better alternatives for compile-time reflection.

Don't forget that libnop also has NOP_EXTERNAL_STRUCTURE (and friends) to decouple the annotation from the structure definition. This is handy when you have a C ABI with C++ internal implementation. I don't recall seeing a similar facility in other libraries.

Most of the above macros work this way. Boost fusions macro will let you specify arbitrary code for getting and setting attributes.

cereal supports shared_ptrs and unique_ptrs, this doesn't (pls correct me if I'm wrong).

unique_ptr and nop::Optional<unique_ptr<T>> is on the way. shared_ptr opens up the ability to create cycles, which are not supported yet.