While looking for a serialization framework, I came across cereal, which looks pretty capable and modern. Adding support for Juce data types doesn’t even require Juce to be changed. Cereal supports class versioning and polymorphic hierarchies. It looks like it is easily maintainable and extensible by template specialisation.
The only point to dislike, at least for me, is the use of ancient XML and JSON libraries (rapidxml, rapidjson) with method arguments like const char* filename , for example. Cereal itself however is making extensive use of C++11.
A quick and dirty Juce module for cereal that I just fired up compiles fine. Not tested much yet.
Has anyone used cereal before? Is this a path worth going down?
The XML output is extremely verbose (deeply nested, no attributes used) and not nearly as beautiful and readable as hand coded Juce XML, which allows for better use of tags and attributes. I can imagine cereal really shines with binary files, though, where nesting is not needed.
Oh, and of course one could write a Juce-based XML loader/saver and hook it into the system, but that would not reduce the depth and verbosity of the output.
Still, the cereal library is a great example for learning some new C++ template tricks! (at least for me). I like how simple it is to pull member variables into the serialisation. It’s probably as good as it gets, lacking reflection in the language.
I’ve used Cereal for work with my day job. It’s an excellent, portable serialization library. However I think JUCE has built-in serialization which is better if you want JUCE specific support help here, but it’s not portable when you want to also have code working in non-JUCE applications.
