Enh: deserializing_iterator<T>::deserialize_into

[Dan Bonachea]

This issue is forked from discussion in pull request #245.

Currently when a non-TriviallySerializable object is read from a view, there's no way to avoid that object hitting the program stack, because the only available deserialization mechanism is deserializing_iterator<T>::operator*() that returns the deserialized result by value. IIUC there's no fundamental reason we can't have an additional accessor that deserializes into provided space (eg properly aligned heap storage) to avoid copy/move overheads for large types that are destined for the heap.

Strawman Proposal:

template<typename T>
deserialized_type_t<T> *deserializing_iterator<T>::deserialize_into(void *storage) const;

Precondition: The iterator must be pointing at a valid element in a view<T, deserializing_iterator<T>> (i.e., and not view::end()).

storage must point to a location with appropriate space and alignment for an object of type deserialized_type_t<T>. Reads the serialized representation of an object of type T referenced by this and constructs a deserialized object of type deserialized_type_t<T> in the memory denoted by storage. Returns a pointer to the newly constructed object.

UPC++ progress level: none

Discussion:

I'm open to naming suggestions. This does conceptually the same thing as [Reader]::read_into, but works on a deserializing_iterator<T> instead of an abstract Reader and is valid to call outside a deserialize() function, which is why I'm suggesting a different name. We could possibly also have a deserialize_sequence_into(void *, size_t), but I don't think that offers any benefit over a trivial loop around deserialize_into

[Amir Kamil]

Resolved by PR #51.