Serializing a vector of pointers about libnop HOT 3 CLOSED

Hello,

Serializing pointers is not currently supported by the library. This is to avoid the potential for cycles, which would result in infinite recursion. The plan is to eventually support cycle detection, but there isn't a concrete timeline for this feature.

Can you share more details about your use case that requires using std::shared_ptr?

from libnop.

I was eventually able to use cereal to serialize the shared pointers. Perhaps you could draw inspiration from their implementation?

I was initially drawn to this library for its simple .Write, .Read serializer sematics, less convoluted as other libraries that try to do same. Adding versioning to the dump file with libnop was a breeze too.

To address your question, i have a bunch of std::maps of std::vectors of objects constructed on the heap - classes and sub classes, huge mess. But hey, at least they are smart pointers.

I believe there is a need for smart pointer serialization, no? Never used it before but from what I read, boost::serialization supports it too.

from libnop.

It wouldn't be hard to add support for std::unique_ptr, as it provides a reasonably strong guarantee that there are no referential cycles. Would this address your use case?

Supporting std::shared_ptr and std::weak_ptr requires additional tracking to avoid infinite recursion when there are referential cycles. The tracking is not particularly difficult, however, it requires additional memory on both serialization and deserialization. The library is designed to avoid internal dynamic allocation; cycle detection is somewhat in conflict with this design principle, though it is not insurmountable.

Another issue is that pointers encourage polymorphism. Polymorphic types are not supported by the library as they lead to ambiguity in the type-to-format mapping. Addressing the ambiguity requires additional bytes in the data stream to describe which type or subtype is encoded. This both bloats the data stream and leads to increased runtime overhead.

Polymorphism also breaks bidirectional binary compatibility. A program compiled with an earlier version of some polymorphic type won't be able to successfully decode a data stream generated by a program with a later version that has more subtypes. As I'm sure you are aware, object slicing can lead to difficult-to-detect bugs.

I'm glad you found a solution for your use case. Cereal is a good library!

Thanks for the feedback!

from libnop.