Re: [boost] Comparison of serialization results

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" <ramey-AT-rrsd.com> wrote:

>>  The only legal technique I've
>>   seen for that is at https://gist.github.com/1528856, 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 
http://bloglitb.blogspot.com/2010/07/access-to-private-members-thats-easy.html
(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
comments.

> 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
http://bloglitb.blogspot.com/2010/07/access-to-private-members-thats-easy.html,
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
http://www.boostpro.com