Re: [Boost-users] [serialization] counting the xml cost

Subject: Re: [Boost-users] [serialization] counting the xml cost
From: Michael Powell (mwpowellhtx_at_[hidden])
Date: 2013-04-20 15:58:24

Hello,

I am trying to follow the code in
http://www.boost.org/doc/libs/1_53_0/libs/serialization/doc/serialization.html
and finding non-member function void
boost::serialization:save(Archive&, ...). What am I doing wrong?

As the name suggests, I would like to split the load and save
concerns. From what I can tell, needs to be in the
boost::serialization namespace? Anything else?

Thank you...

Regards,

Michael Powell

On Sat, Apr 20, 2013 at 11:03 AM, Michael Powell <mwpowellhtx_at_[hidden]> wrote:
> Hello,
>
> Basically, I'd like to find out how well the boost serialization
> facilities handle Xml and to what degree, robustness, etc.
>
> I am counting the cost of serialization for our model. We'll need do
> some basic CRUD type operations on our model objects throughout our
> system, and I want to use a nicely loosely coupled solution. Xml is
> the thought at first; I've also considered a lightweight database like
> SQLite which transfers easily for patches, upgrades, and other
> transfers.
>
> Looking at the boost serialization facilities, one keyword was
> emphasized in the tech-agnostic serialization documentation. Tech
> meaning whether this is a binary file, text, JSON, Xml, whatever. The
> keyword being that serialization and load occur in the same order.
>
> Enter the desire for Xml. One common problem in .NET C# land, at any
> rate, is that reads are commonly known as being asymmetric from
> writes. That is, not guaranteed to happen in the same order,
> composition, whatever. That is, you may see attributes in one
> instance, where as in another the element might have been broken out.
>
> Such as: <myObject name="something" /> and
> <myObject><name>something</name></myObject> are technically the same.
> The serializer might scoff at that, but I'm not sure the W3C suggest
> otherwise. That's my loose understanding of the specification.
>
> Regards,
>
> Michael Powell