Handle reconstruction of virtual serialized types sensibly

[lifflander]

This will allow users to skip that if they allocate the object for themselves and don't need it.

[PhilMiller]

I think I found a bug in allocateConstructForPointer in the non-virtual case, which is called by serialize(unique_ptr) - it reconstructs unconditionally, regardless of unpacking or not

[PhilMiller]

There's a philosophical question this work raises - if we're unpacking into a pointer that has a pre-reconstructed object, of the right type, should we trust that its serializer will get it into the right state and thereby avoid reallocating, or should we always reallocate?

I'm inclined to say that a serialize method should be treated like the set of 'special' methods in C++ that have to maintain construction/lifetime invariants - i.e. copy constructors and assignment operators. Thus, it should be expected to always get the object into the right state from an unpacking serializer, regardless of how it may have been constructed or subsequently modified.

[PhilMiller]

After thoroughly revising this in concert with the implementation of serialize(SerializerT s, unique_ptr p), I've found that there's no reason to actually expose the split. We can just choose not to allocate and overwrite in the apparent reconstruction case.

[PhilMiller]

@bathmatt You may want to look at this also.

[lifflander]

I think I found a bug in allocateConstructForPointer in the non-virtual case, which is called by serialize(unique_ptr) - it reconstructs unconditionally, regardless of unpacking or not

I believe the intention of allocateConstructForPointer is to only be called in the unpacking path by the user.

[lifflander]

There's a philosophical question this work raises - if we're unpacking into a pointer that has a pre-reconstructed object, of the right type, should we trust that its serializer will get it into the right state and thereby avoid reallocating, or should we always reallocate?

I'm inclined to say that a serialize method should be treated like the set of 'special' methods in C++ that have to maintain construction/lifetime invariants - i.e. copy constructors and assignment operators. Thus, it should be expected to always get the object into the right state from an unpacking serializer, regardless of how it may have been constructed or subsequently modified.

I agree on this point. The serialize should guarantee that it gets the object back into the right state regardless of the starting point.

[PhilMiller]

Discussion on EMPIRE call concluded that

• we can keep the singular call, possibly with a rename
• that call should internally handler isUnpacking and in-place deserialization
• the call should be made unconditionally

[PhilMiller]

Addressed in #152