Hi,
I am currently using a C++ library (live555) to which I have added my own subclass, and this work is my first experience with C++.
I need to get access to a pointer that is a private pointer in the parent class. Because I am using an exisiting library I am trying to limit my changes to the library to the extent I am able (hence making it protected is something I want to avoid).

Any input on how to get access to the private pointer variable? Create a getPointer() const; type method? Is there any other way I can possibly get access to the variable when I am working on an instance of a subclass?

Thanks for any input!

MsUpstream

> I need to get access to a pointer that is a private pointer in the parent class.
The bad news is that there's no safe way to do that. Private members are private for a reason, are you sure you really need access to the pointer? Edward finds it hard to believe that the library is so badly written that you can't use it without data access hacks.

Thank you so much for a rapid reply Edward!

The fact that private members are so for a reason is of course the cause of my question (otherwise I might have just made the variable public).

The library (live555) I believe is very well written. It has support for creating media streaming servers and clients. Upon i.e. closure of a media file (ByteStream), the parent class of the ByteStream will then have a private pointer to a function and call that function with the corresponding private pointer to the parameter (an object). This can occur when a handleClose(void * param) event needs to be triggered. I am needing a new type of event that is not implemented in the library, a handleLoop(void * param) (as I am looping a specified segment of a file. The library also has a readMore(void * param) type event)). To do it the 'proper' way I suspect would be to do a lot of changes to the entire library.

The pointer to the parameter (the object) used in conjunction with the handleClose() function is the same one as I would need for the handleLoop(). However, I am in a child class, and not in a place where I have access to the parameter.

Because of the reason you mention I am hesitant to add a simple getParam() const; function. I have been pondering if it is possible to implement a virtual function in the parent class that will be able to use the private variable (?). However, here my limited knowledge of C++ becomes a stumbling block...

You're talking as if you're able to change the code of the parent class. If that's the case then you can write your own function that grabs the pointer and make it a friend from within the parent:

typedef void (*handle_t)(void*);

class Parent {
  friend handle_t PrivateGet(const Parent& parent);
};

handle_t PrivateGet(const Parent& parent)
{
  return parent.privateMember;
}

The big problem here is accidentally breaking invariants that the library assumes won't be broken because the member is private. When you're not supposed to have access to something, it's easy to misuse it.

If you're not able to change the code of the parent class, Ed definitely recommends changing your tactics even if it means more work for you. There are a couple of tricks for subverting the access rules, but they're collectively a Bad Thing™.

I am fully able to add to the library and change it as I am using the source code. My thinking is that it is better to add functions, rather than change existing ones. It makes it easier for me to recognize what I have written, as well as ensuring backward compatibility (when using it for example with vlc/mplayer).

I was hoping there would be some easy solution to the problem. Perhaps that is just not the case. It is a big library, so I am a bit of a coward about bigger changes or additions ;-)

Adding a virtual method will also work. That would probably be easier than a friend function, but the same caveat applies: when you use private members, you can't be sure what the controlling class assumes about when and how it can be used.

Thanks again Edward!

Out of curiosity - can a static function be used in a similar way as a virtual function for my purpose?

If there is truly a legitimate reason for a subclass to want to access a field, it should be declared "protected".

If there is truly a legitimate reason for a subclass to want to access a field, it should be declared "protected".

Yeah I agree. However, with the library I am using I don't have a clue if there is a specific reason to why the variable in discussion was kept private and not put as protected. I realize that it is just good practice to keep things private unless you need them somewhere else. The trick then is to know if a private variable is so for a specific reason, or just because of common conventions. It is also a good reminder of the importance of well commented and documented code :)

Thanks for all input. I hope I know what my options are at this point, and I am very thankful for the input I have been given!

This question has already been answered. Start a new discussion instead.