Separating actual boost transition layer (operator&, <<, >>) with the versioning
stuff, which is now a feature of cereal on its own.
Moving macro for defining version information into cereal.hpp to make it visible.
Added code level (doxygen) documentation for these features
See issue #22
Simple case of making these functions for the rest of the output archive serialization functions and then adding it to
load. Progress towards issue #8.
Remaining things to do: Modify cereal.hpp to properly choose between
versioned and non-versioned functions and place entries in the set of
versioned types as appropriate.
Had to split apart the structs that were being serialized by both boost and cereal
as we no longer allow a type to have both versioned and non-versioned serialization functions
Cleaned up the implementation a little, I'm sure it can still be optimized further. Undid some hacky things in
rapidjson that the old implementation utilized.
All containers that used insert during loads (map, unordered_map, set, unordered_set)
now use emplace or emplace_hint and move their loaded values into position.
Errors in unittests turned out to be errors in the way the tests were written,
not in the actual XML archive.
Additional errors were due to improper loads in vector<bool>, which is now
fixed.
XML out of order seems to be working fine but the unit tests are running into a crash on the out of order test, which
doesn't show up in the sandbox version of the same thing. Need to debug this and out of order should be good to go
for XML.
modified array to use sizeof(array) instead of sizeof(T) * N
modified C style arrays to use sizeof() and proplery check for arithmetic types before doing a binary serialization
had to make a few changes to rapidjson since it uses constexprs in one location,
also had to make sure we used the correct sprintf in a place where we inserted the code
I tried out a few things with traits to try and get things like:
template <class Archive>
void load( Archive const & ar, MyType const & t ) {}
to be errors (note the const). I don't think it's possible to detect this stuff
in the traits that check if these exist, but we can probably catch it in the processImpls
