Re:[boost] [Serialization] Why is serialize() not static?

From: Robert Ramey (ramey_at_[hidden])
Date: 2003-12-03 11:44:32

Douglas Paul Gregor wrote:

>I've been looking at the latest draft of the serialization library and I'm
>wondering why the serialize member function is not static.

If it were static, it wouldn't have access to the member data of
a specific instance.  It is this instance data which is being
saved/loaded.

>By definition, isn't the schema for serializing any particular data type a property of
>the data type

it is, that's why there is one serialize function / data type.  and one invocation / instance

>A static serialize() would give the Archive member data pointers
>instead of actual pointers; if nothing else, this would prevent users from
>passing temporary variables to the Archive (unless there is a use case for
>this?).

I do not understand what you are saying here.

>	1) Ability to generate a DTD (or some other XML schema) for a
>particular data type (and all children) given only the information in the
>serialize() member function (no instances, anywhere).

While, makiing the XML archive, I did consider the possibility of generating
and XML schema at the same time the XML data was being generated.
I chose not to do this as I've got quite a lot to do.  It would be possible
to do this - or make another archive which generated a schema instead
of the actual XML data.  I would however require a an instance of the data
structure to do so - perhaps someone might find this objectionable.

>	2) Ability to check an XML document against the above implicit DTD
>without attempting to deserialize any objects in the document.

When an XML archive is loaded, it pretty much better be exactly in sync with
the serialization specification or its going to throw an exception.  The serialization
specification is the functional equivaltent of the XML DTD in this context.

>	3) Ability to construct an XML "view" into a live object, such
>that modifications to the XML view and show up in the object and
>vice-versa. This is the most important aspect of said XML library.

This library looks at this problem from the other end.  We work in C++
save the state to XML where it might be viewable by other tools.  Modifications
to the XML "view"  would necessarily be very limited as the generated
XML schema is tightly coupled to the C++ data structures to which it
corresponds.

There are products that look at it from the XML end.  that is, XML
is transformed to C++ datastructures for usage  in a C++ program.
Of course we still have the tight coupling.

Finally there is the representation of XML as a dynamic C++ structure.
This is the only thing that can be kept "in sync" with alterable XML . 
This is the issue addressed by DOM, SAX, etc and is an entirely
different thing that what we aspire to do here.

>	4) I think I need to tell the difference between a reference data
>member and a non-reference data member. The former isn't serializable, but
>with the current serialize() interface we can't tell that.

The serialize member function specifies how each member variable is treated.
The reference/non-reference status of a member variable is "known" to 
this member function.

BTW, in our system a reference member is in fact serializable if that is
required by the application.  The manual describes how to do this in the
secton "Non-Default Constructors"

I think my ideal interface would have serialize functions looking like
this:

>class Foo : public Bar {
>  template<typename Archive>
>    static void serialize(Archive& ar, unsigned int version)
>    {
>      ar("Foo")
>      .template base<Bar>()
>      .member("x", &Foo::x)
>      .member("y", &Foo::y)
>      ;
>    }

>  int x;
>  float* y;
>};

This won't compile as x and y are not static so they can't be referenced from within
a static function.  serialization of a class instance must have access
to the instance data.

Robert Ramey