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