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

From: Douglas Paul Gregor (gregod_at_[hidden])
Date: 2003-12-03 14:22:43

On Wed, 3 Dec 2003, Robert Ramey wrote:

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

Not necessarily true. If the Archive object has a pointer/reference to the
instance, it can just use ->* or .* having been given the
pointer-to-member.

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

I'm referring to this comment in the "Advice" section of the
documentation:

        * Prefer serialization of class member variables to temporary
variables allocated on the stack. Scrutinize any cases where this seems
unavoidable. This will guarantee that all distinct objects have different
addresses.

My question for you: are there any cases where this is unavoidable?
The use of data member pointers will eliminate this as a problem,
because an attempt to use a local variable will fail to compile.

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

Oh, I'm not asking you to do this at all. However, I think that the
serialize() member function gets a whole ton of useful information about a
particular class type. I'd like to leave the door open for reusing this
information (many, many times I've wanted something like this, but never
been brave enough to force a user to write it <g>), and if we can clean up
what we see as a logical inconsistency (i.e., serialization is a class
property not an object property), all the better.

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

Understood.

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

Right, I'm not even considering this. Just to clarify again: I'm trying
not to ask for any new features for the serialization lib. I think it has
the right features already, and is in good shape. However, the
serialization lib puts a burden on users to write the serialize() member
function so I want to try to make sure that we won't later make them write
"serialize2" to describe aspects of serialization that we missed the first
time around.

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

I was refering to the problem that the Archive ar can't tell the
difference between a member "int x;" and a member "int& x;". It's not a
big deal, but it could be easy for the user to make a mistake handling
this.

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

Neat!

> 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

&Foo::x returns a value xp of type "int Foo::*". The archiver, when it
needs a real address, can just use "&((*the_instance).*xp)" to get it.

With the syntax above, we lose a bit of clarity and we make the user do a
little more work up-front, but we gain a whole lot of information
that, while it may not be used in the serialization library, could benefit
other libraries. It's interesting that the Python lib does something very
similar to this...

You don't need to change your library to accommodate some dumb idea I have
floating around in my head[*], but I do think we need to give
some thought to maximizing the benefit the user gets from adding a
"serialize" member function to his/her class.

        Doug

[*] I'm currently seeing autogenerated DTDs and UML diagrams. Oh, wait,
now it's my advisor giving me a disapproving stare because I'm still doing
e-mail. You're in trouble now... <g>