Boost logo

Boost :

Subject: Re: [boost] Comparison of serialization results
From: Dave Abrahams (dave_at_[hidden])
Date: 2011-12-28 17:15:46

on Wed Dec 28 2011, "Robert Ramey" <> wrote:

>> The only legal technique I've
>> seen for that is at, and
>> Boost.Serialization should probably have support for that approach.
> I looked at this - extremely clever - I expect nothing less from you!

It's not my cleverness; it comes from
(as noted in the Gist title)

I had to spend quite some time analyzing that code to figure out what it
was doing and why it worked, so I wanted to publish a version with

> Actually, too clever in my opinion. Basically we have private: which means
> "don't let anyone outside of here access this !". This is pretty clear.
> Then we add: friend boost::serialization::access "which means - make an
> exception to the above for boost::serialization!". Which is also pretty
> clear. But your method would let
> me get my hands on someone else's private members without their giving
> permission. If this were to happen
> to me, I don't think I'd like it.

Meh, I don't care. As noted in the comments to,
the point of private is to prevent accidental misuse, not to be some
kind of inviolable firewall.

> Users have the option of doing this if they want to avoid having to use the
> friend declaration in some special cases.

Obviously, if you can alter the class declaration to make
boost::serialization::access a friend, that's preferable. The point
would be to provide the means to serialize even when altering the class
declaration was not an option.

This ability to gain access non-intrusively might be useful for
Boost.Python as well (though usually the problem there is access to a
base class virtual function that may well be private, and this technique
can only get you access to a virtual function's final override).

> So I would be skeptical that something like this would be a good thing
> to include in the serialization library.

You're the boss.

Dave Abrahams
BoostPro Computing

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