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 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
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.
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 acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk