See issue #17
Somewhere along the way we've also broken our ability to compile with GCC 4.7.3. We'll have to decide if we care about
supporting 4.7.3 or not. The changes that break this are:
-there is no emplace in std::map (or related) in 4.7.3
-there are some enable_ifs in rapidjson's writer.h that are always false (which is fine), but
GCC 4.7.3 doesn't like this
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
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.
We are significantly faster than boost (up to about twice as fast) when not just dumping binary data. Size seems to be
negligable between the two. Speed goes up as data gets larger. Boost's overhead for metadata is actually pretty small
when the data types themselves are not small. For very small data types, it might start to make a difference.
So far I've only played around with std::vector<double> for size 7 or size 1M, we are smaller when the header is a
significant portion and the same size (though always smaller due to no header) at larger sizes, but we basically run at
the same speed and same size for vectors of doubles
