Still some kinks to work out in regards to trait checks on a non-member
load_minimal that accepts everything as template parameters and does
enable_if style checks
Even though there is currently no need to use this archive parameter, it is now
passed to the various minimal serialization functions instead of simply being
a template parameter.
The reason for this was ultimately allow for correct name-lookup of the functions
using ADL when the type was unable to provide this (e.g. a generic serialize function
for enums written in the cereal namespace).
Also fixed some issues with GCC 4.7 and the various traits that warn if the type for the
load isn't passed by const ref. Had to use a workaround found here:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51213 (=delete instead of private).
The following preprocessor defines have been added:
- CEREAL_SERIALIZE_FUNCTION_NAME
- CEREAL_SAVE_FUNCTION_NAME
- CEREAL_LOAD_FUNCTION_NAME
These defines specifiy the name of the cereal serialization/deserialization
functions so that they can be customised by users. This is especially useful if
the user would like to have capitialized function names.
If someone attempts to have both a versioned and non-versioned serialization
function, they will get a compile time error.
relates to improvements in #23
Also fixed a bug with some type traits that would erroneously return true if
an odd number of boolean variables were true when the desired behavior was to return
false if more than one boolean variable was true.
Need to revise the no matching serialization to properly fire if a type is specialized
but has both versioned and non-versioned functions of the specialization type.
longs should now properly serialize under 32 or 64 bit machines.
long long, unsigned long long, and long double now serialize as base10
strings instead of base64.
see issue #72
Modified the polymorphic saving of pointers to use a second
shared_ptr to manage the refcount of the wrapper proper polymorphic
shared_ptr (previously we were using an empty deleter). The result of
this is that the wrapper doesn't actually manage the pointer it holds,
it just allows access to it so long as there is still a refcount in
the second refcount pointer.
Modified the polymorphic wrapper and enable shared from this state
saver to be RAII style.
This fixes issue #65, however, this comes at a mild consequence for
anyone wishing to serialize types that inherit from std::enable_shared_from_this.
cereal no longer supports this inheritance if done using the protected access
modifier without befriending cereal::access.
For example, consider all of the following (pretend they are polymorphic)
serialized with some smart pointer:
struct A : std::enable_shared_from_this<A> {}; // OK
struct B final : protected A { friend class cereal::access; }; // OK
struct B2 final : protected A { }; // ERROR: cereal can't access enable_shared_from_this
struct C : A {}; // OK
struct D {}; // OK - a normal class with no enable_shared_from_this
Apparently MSVC doesn't want typename where it makes sense to use
typename (dependent type from a template). Preprocessor verbosely
saves the day, yet again. Relates #68
cereal no longer permanently modifies the state of internal workings of
std::enable_shared_from_this when saving. cereal *should* be completely
compatible with both saving and loading anything that inherits from this now.
This fixes issue #68 - note that there is still a minor issue regarding
classes declared final that will run into a bug with the way we check for
enable_shared_from_this (see issue #65).
Issue #65 will be addressed in the future by changing the way we check
for derivation from enable_shared_from_this. In the current scheme, we
can detect this even if you use protected inheritance. In the future, cereal
will not be able to get around protected inheritance of enable_shared_from without
befriending cereal::access. This will come at the benefit of allowing classes
declared final to be used with polymorphic serialization.
cereal will now override RAPIDJSON_ASSERT by default to throw a
runtime exception instead of failing an assertion. This can always
be overridden by defining your own RAPIDJSON_ASSERT macro
see #67
