Access to protected member through member-pointer: is it a hack?

We all know members specified protected from a base class can only be accessed from a derived class own instance. This is a feature from the Standard, and this has been discussed on Stack Overflow multiple times:

• [Cannot access protected member of another instance from derived type's scope ](https://stackoverflow.com/q/45146025/5470596 "a similar question on Stack Overflow");
• [Why can't my object access protected members of another object defined in common base class?](https://stackoverflow.com/q/17717027/5470596 "a similar question on Stack Overflow")
• And others.

But it seems possible to walk around this restriction with member pointers, as user chtz [has shown me](https://stackoverflow.com/a/49538355/5470596 "their answer to a related question"):

struct Base { protected: int value; };
struct Derived : Base
{
    void f(Base const& other)
    {
        //int n = other.value; // error: 'int Base::value' is protected within this context
        int n = other.*(&Derived::value); // ok??? why?
        (void) n;
    }
};

[Live demo on coliru](http://coliru.stacked-crooked.com/a/7680e07f219a73a7 "(external)")

Why is this possible, is it a wanted feature or a glitch somewhere in the implementation or the wording of the Standard?

---

From comments emerged another question: if Derived::f is called with an actual Base, is it undefined behaviour?

The fact that a member is not accessible using class member access expr.ref (aclass.amember) due to access control [class.access] does not make this member inaccessible using other expressions.

The expression &Derived::value (whose type is int Base::*) is perfectly standard compliant, and it designates the member value of Base. Then the expression a_base.*p where p is a pointer to a member of Base and a_base an instance of Base is also standard compliant.

So any standard compliant compiler shall make the expression other.*(&Derived::value); defined behavior: access the member value of other.

> is it a hack?

In similar vein to using reinterpret_cast, this can be dangerous and may potentially be a source of hard to find bugs. But it's well formed and there's no doubt whether it should work.

To clarify the analogy: The behaviour of reinterpret_cast is also specified exactly in the standard and can be used without any UB. But reinterpret_cast circumvents the type system, and the type system is there for a reason. Similarly, this pointer to member trick is well formed according to the standard, but it circumvents the encapsulation of members, and that encapsulation (typically) exists for a reason (I say typically, since I suppose a programmer can use encapsulation frivolously).

> [Is it] a glitch somewhere in the implementation or the wording of the Standard?

No, the implementation is correct. This is how the language has been specified to work.

Member function of Derived can obviously access &Derived::value, since it is a protected member of a base.

The result of that operation is a pointer to a member of Base. This can be applied to a reference to Base. Member access privileges does not apply to pointers to members: It applies only to the names of the members.

---

> From comments emerged another question: if Derived::f is called with an actual Base, is it undefined behaviour?

Not UB. Base has the member.

Just to add to the answers and zoom in a bit on the horror I can read between your lines. If you see access specifiers as 'the law', policing you to keep you from doing 'bad things', I think you are missing the point. public, protected, private, const ... are all part of a system that is a huge plus for C++. Languages without it may have many merits but when you build large systems such things are a real asset.

Having said that: I think it's a good thing that it is possible to get around almost all the safety nets provided to you. As long as you remember that 'possible' does not mean 'good'. This is why it should never be 'easy'. But for the rest - it's up to you. You are the architect.

Years ago I could simply do this (and it may still work in certain environments):

#define private public

Very helpful for 'hostile' external header files. Good practice? What do you think? But sometimes your options are limited.

So yes, what you show is kind-of a breach in the system. But hey, what keeps you from deriving and hand out public references to the member? If horrible maintenance problems turn you on - by all means, why not?

Basically what you're doing is tricking the compiler, and this is supposed to work. I always see this kind of questions and people some times get bad results and some times it works, depending on how this converts to assembler code.

I remember seeing a case with a const keyword on a integer, but then with some trickery the guy was able to change the value and successfully circumvented the compiler's awareness. The result was: A wrong value for a simple mathematical operation. The reason is simple: Assembly in x86 does make a distinction between constants and variables, because some instructions do contain constants in their opcode. So, since the compiler believes it's a constant, it'll treat it as a constant and deal with it in an optimized way with the wrong CPU instruction, and baam, you have an error in the resulting number.

In other words: The compiler will try to enforce all the rules it can enforce, but you can probably eventually trick it, and you may or may not get wrong results based on what you're trying to do, so you better do such things only if you know what you're doing.

In your case, the pointer &Derived::value can be calculated from an object by how many bytes there are from the beginning of the class. This is basically how the compiler accesses it, so, the compiler:

1. Doesn't see any problem with permissions, because you're accessing value through derived at compile-time.
2. Can do it, because you're taking the offset in bytes in an object that has the same structure as derived (well, obviously, the base).

So, you're not violating any rules. You successfully circumvented the compilation rules. You shouldn't do it, exactly because of the reasons described in the links you attached, as it breaks OOP encapsulation, but, well, if you know what you're doing...