Object serialization

this is more a poll to ask for opinions and experiences on
serialization of objects. What toolkit do you use? If not using a
toolkit do you have your own serialization framework? What techniques
are you using? I used the boost serialization framework but - besides
the fact of having all the macros and recursive templates - it does
not work with objects from different dlls, so I am looking for
something else. Any help appreciated!!!!

BR

-- dimitris

http://www.parashift.com/c++-faq-lite/serialization.html

I tend to write my own per-class serialize and deserialize methods. To
back them up, I use a class I've written as part of the General
Systems Library project; gsDataPacker. It's a simple class with
template methods for packing and unpacking primitive types into and
out of data buffers. When I want to build serialization into a class,
I use gsDataPacker's static methods to pack and unpack member objects.
It's a simple approach that works quite well.

If you are talking about binary serialization you could
consider www.webebenezer.net.

I don't know if it works with objects from different dlls, but
it doesn't require macros or friend declarations. It is an
online service so downloading, building and maintaining
the installation aren't required.

Brian Wood
Ebenezer Enterprises

Hi Brian,

BOOST_SERIALIZATION_SPLIT_MEMBER, BOOST_CLASS_VERSION and so on are
macros that make my code impossible to read and maintain, because if
something goes wrong, I don't have the code that gets compiled, as it
is the case now for me...

Regards,

Dimitris

Shalom, Dimitris,

The B.Ser author has used macros liberally and the result is
not surprising. The BOOST_CLASS_VERSION macro is kind of the
tip of an iceberg. I'm skeptical of the approach to version support
advanced by Boost. It encourages users to have one
class for multiple releases and use if statements to figure
out which fields to work with based on the version number.
I think having separate classes when something needs to be
changed between releases is a better approach. Consider the following
scenario:

AccountBase {};

Account : public AccountBase {};

Account_13 : public Account {};

Say there are releases 1.1, 1.2 and 1.3. The Account
class is used in 1.1 and 1.2 but needs to be changed
in 1.3. The 1.3 server needs to support 1.1 and 1.2
clients. The Boost approach suggests using one class,
I'll call it B_Account, to support all of the releases.
Using a B_Account to support 1.1 clients (in a 1.3 server)
is probably wasting memory/time because it has fields in
support of 1.3 as well. And if a 1.3 client sends a
B_Account and an error occurs in the reception of the 1.3
part of the class, there is no sane way to use the 1.1
portion.

I'll explain how this could be handled better now.
Currently in C++, if the constructor of a derived
class throws an exception, the already constructed
sub objects will be destructed. IMO this default
behaviour is dubious in distributed apps. It should
be possible to write something like:

AccountBase* account = new (preserve) Account_13(...);

that would preserve a successfully constructed Account
object when an exception is thrown from Account_13's
constructor. The sender, network and receiver of the
object have put in too much work to throw it all away.
The 1.3 server is able to work with 1.1 Accounts
already so this fits in well with the big picture.

If I were using B.Ser I would want to avoid what it
refers to as "versioning" support.

Brian Wood
Ebenezer Enterprises
www.webebenezer.net