Interest in cpp-member-accessor?
Dear all, 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. I think this should be integrated in Boost, is there interest other from myself? Before you say it is evil, consider all the good that can be done with this in responsible hands. You can add serialisation support to classes that you do not control and you can write efficient Python bindings. I have used this library now in three projects. I used it to add serialisation support and to provide memory views of C++ structures in Python (via the Numpy module), both wouldn't have been possible to do or not would not have been efficient without this. It is a single-header library with 85 lines of code, some of which are comments. This seems a bit small for a separate library, but I am not sure where it would fit in. Best regards, Hans
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.
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
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. libraries without enthusiastic support from their original author.
Before you say it is evil, consider all the good that can be done with this in responsible hands. You can add serialisation support to classes that you do not control and you can write efficient Python bindings. I have used this library now in three projects. I used it to add serialisation support and to provide memory views of C++ structures in Python (via the Numpy module), both wouldn't have been possible to do or not would not have been efficient without this.
I 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.
On 7. Feb 2023, at 00:21, Gavin Lambert via Boost
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.ht...
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.
On Mon, Feb 6, 2023 at 1:22 AM Hans Dembinski via Boost
This is very interesting. However, given that: 1. It enshrines a generally bad practice, and 2. It is only an 85-line library (including comments and whitespace). I think it would be better for this to stay out of the Boost library collection. Users who need it, can simply inline the header or code into their existing code base; preferably as an implementation detail and not as a public interface. Thanks
On 7. Feb 2023, at 00:57, Vinnie Falco
wrote: I think it would be better for this to stay out of the Boost library collection. Users who need it, can simply inline the header or code into their existing code base; preferably as an implementation detail and not as a public interface.
I understand your angle, and you are right that the library does not expose types that could appear in a public API, so it does not require standardisation. But is that the only thing we want from Boost? The benefit of having this in Boost is to make this sharp tool available to a larger audience, and to have a nice API for it. The current one by the original author can be improved. We are also discussing occasionally how Boost can stay relevant. I think providing expert tools like this can help.
participants (3)
-
Gavin Lambert
-
Hans Dembinski
-
Vinnie Falco