Re: Interest in cpp-member-accessor?

From: Hans Dembinski (hans.dembinski_at_[hidden])
Date: 2023-02-07 10:08:59

> On 7. Feb 2023, at 00:21, Gavin Lambert via Boost <boost_at_[hidden]> wrote:
> 
> On 6/02/2023 22:22, Hans Dembinski wrote:
>> Hubert Liberacki wrote this library
>> https://github.com/hliberacki/cpp-member-accessor
>> that uses a loophole in the C++ standard which allows one to access
>> private members and methods in classes in external libraries that are
>> not under the control of the library author. Since the loophole is
>> legal, it works with all major compilers and on all platforms. No
>> special compiler flags required nor illegal macros like #define
>> private public.
> 
> Interesting; I was aware of the technique and have used it in a couple of places where it was needed, but was not aware of this library.

I should add that Hubert did not invent this technique. It is at least 13 years old. The README of the repository traces it back to a post by Johannes Schaub, which in turn got inspired by a commit of the clang compiler.

http://bloglitb.blogspot.com/2010/07/access-to-private-members-thats-easy.html?m=1

>> I think this should be integrated in Boost, is there interest other
>> from myself?
> Is there interest from the library author in so integrating it? Certainly Boost shouldn't be in the business of integrating external libraries without enthusiastic support from their original author.

I haven't asked, but the library is trivial and would drastically change in code review anyway, I presume, so I think it does not really matter whether the original author supports it. I would implement it and go through code review if people here consider it useful.

especially when you are writing serialization and (Python) binding code for legacy libraries. The nice thing about this technique: it is not that brittle. If the source file changes, e.g. the type of the member, then compilation fails.

>  do worry that making the technique too easily accessible might encourage abuse, though.  Even external serialization should ordinarily be accomplished via public members where possible; it's too easy to create brittle code when using private members in the presence of any library upgrades (or library version abstraction as common in package-management systems) or polymorphism.

You are right, but this only for the case where the public API does not allow you to do certain things at all, or when it does not allow you to do it efficiently (avoiding copies). I usually have to deal with old software that is very "stable" but not expertly designed and I need to work around the limitations. In such cases, the use is justified.

Having this in Boost won't encourages abuse. Accessing private members is bad, everyone knows that. If you do it without good reason, your code will be rejected in code review. Projects worried about this can ban the use of this feature, this can be checked automatically with scripts. However, I think doing that is disrespectful to developers. We are not children that need to be locked down so we cannot hurt ourselves. Give me a sharp knife so I can cut my vegetables please.

The Python community shows that strict private-ness as in C++ is not necessary for writing good software. In Python, private members and methods exists, but as a suggestion. You can touch and even modify private members/methods. Some libraries use that to great effect, but in general, people do not touch private stuff, because their code can break on any release.