Boost logo

Boost :

From: Robert Ramey (ramey_at_[hidden])
Date: 2005-10-14 10:36:13

Here is the background/history.

The original inspiration for the serialization library was my experience
with the serialization system in Microsofts MFC library. I liked it but
wanted to make more generalized. I came upon Boot while looking for a
mult-threading "wrapper" which would "guarentee" thread safety if one
followed the wrappers rules. I was very impressed with the thought and
rigor of the boost threading library. Hence I became interested in boost.
At that time there was a small "persistence" project by Jens Maurer. It had
the beginnings of what I wanted a serialization library to do. I was
convinced that to be really useful - a serialization library had to do just
about everything. (Usually, I disagree with suc a notiion - but this case
was an exception). Jen's library had the & operator - which at first
surprised and confused me. I was just starting to understand the usage of
templates beyond simple parameterized class declarations/definitions at it
took me a little while to actually see what the & operator was doing in this
case. Of course it eventually became clear to me and I embraced it. I
provides one huge benefit. It guarentees the saving and loading are
symetric for most usages of the library. This seems like a small thing. But
tracking down obscure asymetries in binary archives turns out to be
surprizingly time consuming. So the existence of the & operator along with
xml archives which can detect asymetric serialization implementation have
effectively eliminated this problem.

To summarize, I included the & operator because Jens did and came to like
the idea.

The question remained - why & rather than some other. From strictly
aesthetic considerations I would ha ve preferred && because it looks like <<
and >>. But I elected not to change it. I suspected that the & operator
was chosen due to its operator precedence being at a particular spot in the
operator precedence hierarchy and I never had any problems with things like

ar & m1 & m2 ...

and having many wheels to invent I was please to presume that this choice
was a studied one and a good one so I accepted it and moved on to fry my own

So that's how we got to where we are.

It has gained, up to now universal acceptance, so I don't see this changing.

Of course, its usage is optional. Also you're free define your own global
function like

serialize(ar, data)

which would be equivalent and suit your own taste.

The usage of << and >> are my own and are obviously analog to the concept of
using << and >> for stream input / output respectively.

So, for better or worse, that's how we arrived here.

Robert Ramey

Jim Hyslop wrote:
> I've been looking at the serialization library (nice work, Robert)
> and I have a question. I searched the archives and didn't see any
> discussion on this, and I'm sorry I missed all the pre-approval
> discussion, or I would have said something sooner.
> What is the rationale behind using 'operator &()' to mean 'serialize
> this item?'
> I find a statement like 'ar & member1;' to be very non-intuitive: how
> does bitwise-and relate to serialization?
> It seems to me that most sensible code guidelines admonish against
> this kind of operator abuse (pardon my bluntness, but that's what it
> is when you get down to it).

Boost list run by bdawes at, gregod at, cpdaniel at, john at