Zitat von Robert Ramey <ramey@rrsd.com>:
David Sankel wrote:
The serialization library describes its feature as a function that converts a supported object to a sequence of bytes and back into an "equivalent structure". The meaning of "equivalent structure" unfortunately isn't defined in the documentation.
Consider the following example:
struct Z { A * a; , B b; };
If we consider syntactic equivalence, the result of serializing this would be something like:
Z{ a=0x029348af, b=B{...} }
If we use semantic equivalence, serialization could result in any number of things, including:
Z { a=new A{...}, b=B{...} }
or even:
Z {}
It depends on what the meaning of a Z is.
The serialization library implements the latter. It never occurred to me to formally define "equivalent structure" as only the latter definition is useful for the purposes for which the library is intended - persistence and marshalling. If anyone want's to suggest an enhancement to the documentation I'll consider it.
I don't see a problem wrt this in Boost.Serialization, implementation- or documentation-wise. the semantics of "equivalence" is defined by the individual serialize() functions in Boost.Serialization. this issue only arises in Intro and possibly in Mirror because we try to deduce the serialization semantics from the member definitions (and some semantics tags), so that serialize() and other algorithm implementations don't have to be overridden for each type. I do think however, with the caveat that I don't know how exactly it was reached, that it wasn't a good design decision to deduce the semantics of a member from its type. especially with object tracking, where the semantics of a pointer is deduced from the pointee type.