cereal v1.2.0 Release Notes

Release Date: 2016-06-30 // almost 8 years ago
  • ๐Ÿš€ 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 or cereal::virtual_base_class. If you do not do this, you must explicitly tell cereal about the relationship using the new macro CEREAL_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.