Cereal 1.2.1 Release
This is the fourth release for Cereal! This update is focused on fixing several bugs that affected the cross-compatibility, usability and stability of the library.
IMPORTANT: This update fixes several bugs. We strongly encourage updating to this version as soon as possible.
Changelog
- Fixed template specialization on Linux (Thanks, @raresica1234!)
- Fixed minor bug in Buffer.h
- Fixed CRC32 calculation error. Now the CRC checksum is compatible with the C# port of the library
- Fixed
int64
anddouble
deserialization bug in Buffer.h - Added randomization to tests
- Added CircleCI for continuous integration & automatic unit testing
- Replaced sandbox program with individual tests for each section of the library
- Added Google Test for unit testing purposes
- Fixed 'tautological compare' warning. Now the library will check for overflows properly
- Fixed vector data reallocation in Array::getArray()
- Changed
std::string
withconst std::string&
when possible to avoid unnecessary string copying - Added functions to copy arbitrary data from buffers
- Deleted copy constructors for all classes to prevent double memory deletion bugs
- Added functions to delete Fields and Arrays from Objects, Objects from Databases, and Databases from Headers
Notes about backwards compatibility
The API itself is fully backwards compatible, but because there was a bug with the CRC32 calculation algorithm, all databases created with Cereal v1.2.0 would trigger a Checksum mismatch
exception when loading with the new CRC32 algorithm.
To solve this, we introduced Databases v2.1. They are identical to Databases v2.0, but use the new algorithm. Cereal will load existing databases with version 2.0, but they'll be automatically updated to version 2.1. Also, it is NOT possible to manually create databases with version 2.0, as the version will silently bump up to v2.1.
What does this mean for all of you using this library? Nothing! If you have existing databases with version 2.0, Cereal will read them, check the checksum using the old algorithm, and update them to version 2.1 should you re-serialize the existing database. If a new database is created, v2.1 will be selected by default unless otherwise specified. Therefore, backwards-compatibility is 100% maintained.