Re: [boost] [Serialization] why operator &()?

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 
fish.

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).