Boost logo

Boost :

Subject: Re: [boost] Comparison of serialization results
From: Neal Becker (ndbecker2_at_[hidden])
Date: 2011-12-29 09:43:13


Dave Abrahams wrote:

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

I'd like to offer a decenting opinion. The use of this is where you need to add
serialization to some existing code which you are not free to modify. I would
find this very useful.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk