Accessing private members

Hello! I would just like to ask what is the best way to access the private members of the base class?

I understand that a derived class only inherits (and have access to) the public and protected members of the base class.
However, I'm working on a project where I'd like to access the private members as well, but I'm not allowed to modify the base class.

One solution I've seen in the forums is to declare the derived class as a friend of the base class.
This declaration is done in the header file of the derived class since the base class cannot be modified, as in the following example.

//Daughter.h
#define private friend class Daughter; private
#include "Mother.h"
#undef private

Could you please advise if this is a good way to do it, or is there a better alternative?
Thank you!
No, using hacks to get hold of private data is generally not a good idea. If the class does not expose something, either though a public variable or a public member function, it is probably a design decision that you should respect, but if you believe it is a mistake you can of course go a head and change the class (or ask the author to change it if it isn't yours).
Last edited on
@coder777, in the example you are referring to, the derived class already has access to those (protected) members, which it then makes public. rookie000 wants to be able to "do the impossible". He wants to access the private members of the base class.

@rookie000, I can't think of another way of doing it, but maybe one of the super-experts can. You basically are modifying the base class. You're just modifying it on the fly at compile time.

EDIT: And as Peter87 said, it is a total hack. (Maybe okay for debugging, though?) If you really need access to something in the base class that you can't access then there's obviously a problem in the design.
Last edited on
I'd like to access

Like? As convenience? I'd like to get billion dollars then.

Alas, like to is not same as need to.

If you don't need access, then you don't. If you would really need access, then either base class interface has to change, or you don't use that base class at all.
every once in a while some API that you bought hides something you need, and its almost always just something you want to print to either debug your own code or its needed and the original authors didn't think to let you see it. Its rare, but that kind of thing does happen, esp in the hardware APIs. Sometimes hacking in is the only way to get it. Avoid it if you can, fix it if you can, and if nothing else is possible, grab a pointer to it. But the one thing you do not want to do is modify it. Looking is harmless, but if you modify something you almost always will break something and it could be very subtle.
#define private friend class Daughter; private
This is undefined behavior. Nevertheless, you can use some arcana to do this without breaking the language rules.

As I understand, the technique was "popularized" by Johannes Schaub in this post:
https://bloglitb.blogspot.com/2010/07/access-to-private-members-thats-easy.html

Here's an annotated example explained by Dave Abrahams (I think this snippet is easier to understand.)
https://gist.github.com/dabrahams/1528856

You can maybe ask your compiler to disregard access specifiers entirely. GCC and Clang, for example, support the -fno-access-control flag, which does what you want.

The nicest solution, of course, is not to access private data at all. Doing otherwise invites all sorts of bugs.
Last edited on
Schaub links to Sutter, who quoted Meyers:
there are times when it's tempting to have a quick way to bypass the access control mechanism temporarily, such as to produce better diagnostic output during debugging... but it's just not a habit you want to get into for production code, and it should appear on the list of "one-warning offences" in your development shop.
Hello, thank you very much for your feedback. I agree that it will be better if I don't access the private functions. I'll take your advice and try to do that. Thanks again! :)
Last edited on
Topic archived. No new replies allowed.