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.
Previously we took the address of the dereferenced begin() iterator
on a string to get the pointer to its data; we now just const_cast
the pointer that is the result of calling data().
The original reason for using the iterator over something like data()
was to avoid the const_cast and to ensure that any copy on write
mechanisms were used, but this doesn't seem necessary given that we
call resize() immediately prior to this. Valgrind shows no problems
with the new method. Also added unit tests for this case to string.
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
Previously if you had an archive that supported eliding empty classes
(such as binary or portable binary), and specialized that archive there would
be an ambiguity in the enable_ifs for serialization.
