cereal v 1.2.0
This is a minor feature and bug fix release for cereal.
This release sat around (much) longer than expected - note that the develop branch can always be used to access the latest changes to cereal.
Notable changes include:
- RapidJSON updated to a recent version (#121)
load_and_construct
now supports versioning (#216)- Bug fixes for polymorphism and multiple inheritance (#188, #281). See the documentation regarding the new requirement for paths between base and derived classes and read the breaking changes below for more information.
Minor fixes and enhancements include:
- Improved control over endianness for portable binary archive (#115)
- Improved documentation (#201, #269, others)
- Polymorphic support pulled in automatically with
<memory>
(#193) - RapidJSON and RapidXML placed in cereal namespace (#121)
- Various CMAKE improvements (#222 thanks to @robiwano, #239 and #254 thanks to @tamaskenez)
See the closed issues for more information.
Breaking Changes:
- As part of improving support for polymorphic serialization, we have introduced a requirement for explicit relations between polymorphic class hierarchies. Whenever you serialize a smart pointer to a polymorphic type, cereal must be able to find a path from the derived type to the base type. cereal is able to do this automatically if you serialize the base class using
cereal::base_class
orcereal::virtual_base_class
. If you do not do this, you must explicitly tell cereal about the relationship using the new macroCEREAL_REGISTER_POLYMORPHIC_RELATION
, found in<cereal/types/polymorphic.hpp>
. std::bitset
has been optimized for binary archives to avoid conversion to a string representation (see #236, thanks to @lyager). As a result of this, any bitset long enough to previously use the string output will not be compatible with the new serialization.
Known Issues
There is currently an error in the compile-time type checking that cereal performs on non-member load_minimal
functions that will cause a static_assertion
to mistakenly prevent compilation from succeeding. This only affects users using non-member load_minimal
functions where the type to support load_minimal
requires an unknown template parameter. See #132 for more information and workarounds.