Thread: Inheritance in Pimpl idiom

Hello everyone,


Why it is useless for any inheritance in Pimpl idiom? Here is the source, but no detailed reasons are provided.

http://www.gotw.ca/gotw/024.htm

--------------------
- make XImpl entirely the class that X would have been, and write X as only the public interface made up entirely of simple forwarding functions (a handle/body variant).

This is useful in a few restricted cases, and has the benefit of avoiding a back pointer since all services are available in the pimpl class. The chief drawback is that it normally makes the visible class useless for any inheritance, as either a base or a derived class.
--------------------


thanks in advance,
George

Originally Posted by George2

Hello everyone,


Why it is useless for any inheritance in Pimpl idiom? Here is the source, but no detailed reasons are provided.

Because inheritance is meant to leverage another class's implementation. But Pimpl is meant to do the opposite -- hide the implementation. You can inherit from the Pimpl interface but you are stuck making explicit calls to the underlying implementation -- you can't take advantage of how inheritance normally works where all the parent class's methods are "just there."

Thanks brewbuck,


I do not quite understand your below comments. Could you provide more description please or some pseudo code? Especially what do you mean "take advantage of how inheritance normally works" and parent class's methods are "just there."?

Originally Posted by brewbuck

but you are stuck making explicit calls to the underlying implementation -- you can't take advantage of how inheritance normally works where all the parent class's methods are "just there."

regards,
George

Originally Posted by George2

Thanks brewbuck,


I do not quite understand your below comments. Could you provide more description please or some pseudo code? Especially what do you mean "take advantage of how inheritance normally works" and parent class's methods are "just there."?

Say you had some underlying class which provides functionality X() and Y(). Suppose the class looks like this:

Code:

class ClassGuts
{
public:
    someThing();
    someThingElse();
};

So the job of the Pimpl wrapper is to implement X() and Y() in terms of someThing() and someThingElse(). The two some*() functions are implementation details. The user will only see X() and Y(). So suppose you inherit from the wrapper. You can still call X() and Y() but you can't access the underlying ClassGuts object because that's the whole point of having a wrapper. You could inherit from ClassGuts directly, but now you've rendered the Pimpl idiom irrelevant.

Thanks brewbuck,


But invoking X() and Y() directly (other than inheriting from ClassGuts directly) will have any limitations? We can achieve some*() functions through X() and Y().

Any disadvantages?

Originally Posted by brewbuck

Say you had some underlying class which provides functionality X() and Y(). Suppose the class looks like this:

Code:

class ClassGuts
{
public:
    someThing();
    someThingElse();
};

So the job of the Pimpl wrapper is to implement X() and Y() in terms of someThing() and someThingElse(). The two some*() functions are implementation details. The user will only see X() and Y(). So suppose you inherit from the wrapper. You can still call X() and Y() but you can't access the underlying ClassGuts object because that's the whole point of having a wrapper. You could inherit from ClassGuts directly, but now you've rendered the Pimpl idiom irrelevant.

regards,
George