Re: [Boost-users] Automating Serialization?

Subject: Re: [Boost-users] Automating Serialization?
From: Brian Wood (woodbrian77_at_[hidden])
Date: 2009-11-27 02:00:12

Stefan Strasser writes:
>Am Thursday 26 November 2009 14:05:18 schrieb Bilokon, Paul:
>> Hi,
>>
>> By design Boost Serialization requires the user to list each field that
>> needs to be serialised.
>>
>> This is in contrast, for example, with Java and some other languages
where
>> serialisation is supported (kind of) at the language level.
>>
>> The current approach requires some code duplication. We have to declare a
>> field. We have to manually (de)serialise it. If we need to make a change,
>> we make it in at least two distinct places.
>>
>> Is there any way to automate the process of serialisation, perhaps
>> harnessing the power of the preprocessor? E.g. we could label the fields
>> that need to be serialised. Is there anything in Boost that could help?
>
>not that I'm aware of, but I even think that's a good thing.
>the serialize() function represents a file format, and you want file
formats
>to be stable and not being changed because someone added a runtime field to
a
>class.

"runtime field" ?

>usually when you do want to add a serialized field you'd also want old
>versions of the file still to be readable, so you end up writing custom
>(versioned) deserialization code anyway, even if your language has built-in
>serialization support.

I recommend avoiding the versioning support in Boost Serialization.
It runs counter to good development practices by averting the type
system.  Consider for example a class called Account that uses
versioning to support multiple releases of a product.  In the usual
case, later releases will have more fields and added complexity
than earlier releases.  Support then for a client at an early release,
say 1.1, becomes inefficient since Account is being used to
handle both 1.2 and 1.1 users.  If instead Account_11 and
Account_12 are used -- with Account_12 probably derived from
Account_11 -- this weakness is avoided.  Additionally this approach
is beneficial from a testing perspective.   In a 1.2 server, 1.1
clients are supported using Account_11, which has already been
tested and is not messed with to support 1.2 clients.

>
>you could use some compile time code generator to write default
serialization
>code for you, using e.g. OpenC++, GCC-XML, or Doxygen, but I doubt those
>generated functions would stay there very long.

I'm not exactly sure what you are saying here, but if a user is
simply improving the names of some of his fields, the functions
won't stay the same very long.  Automating this helps with a
common problem of forgetting to update the serialization
functions and the compiler then barking.  I don't claim though
that every class should be handled this way.  The C++ Middleware
Writer allows users to turn off the automated generation of
marshalling functions if that is desired.  In my experience, it is
unusual to turn that functionality off.

Regards,
Brian Wood
http://www.webEbenezer.net <http://www.webebenezer.net/>

"Then Samuel took a stone, and set it between Mizpeh and Shen,
and called the name of it Ebenezer, saying, so far the the L-RD has
helped us."