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.
Still todo:
* Build under debug/release for both 32 and 64 bit
* make a project for performance
* clean up code specific for vs and take a careful look at the changes that json.hpp needed
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
we're pretty good on every metric tested so far except for vectors of strings, which
for some reason we are slower than boost at. vectors of binary types are basically the same, and vectors of arbitrary
structs are fine, as is individual string processing.
Tried to detect a case where archives were marked as const but this is harder than it seems. Now detecting if load or serialize incorrectly marke their type parameters as const (or are const member functions)
This is to ensure binary compatability between machines of different bit persuasions. cereal::size_type is typedef'd to uint64_t in helpers.hpp for now, but as soon as our 128 bit machines arrive we can change this with a one liner.
closes#10.
Progress towards issue#9, modified unique_ptr<void> to use our empty deleter. Can't do a full test with libc++ because
of various linker errors related to my configuration of libc++. No change in behavior under libstdc++.
