Re: [boost] [intro] Preview: Introspection library

Subject: Re: [boost] [intro] Preview: Introspection library
From: Stefan Strasser (strasser_at_[hidden])
Date: 2010-06-30 12:06:27

Zitat von Robert Ramey <ramey_at_[hidden]>:

> 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.