Re: Hiding implementation
borophyll@gmail.com wrote:
Thank you both for your input. The above methods seem to suffer from
the same problems of roundaboutness as pImpl, with other associated
problems. So I guess it really comes down to the language's design.
Why did C++ choose to not allow a program to define certain parts of a
class in seperate places (eg public interface in header file, and the
rest elsewhere).
I think you are mixing program organisation with the p-impl idiom. It
may be helpful to recap what exactly the problem the p-impl design was
really trying to solve. From what I know, p-impl lets you:
1) redesign part of the class without having to recompile other parts of
the program
2) facilitate fast data swapping between objects. That is, instead of
swapping all data elements, a p-impl class needs only to swap with the
content pointer.
3) share content between objects (not primary purpose)
AFAICS, problem 1) is a non problem from a language design perspective.
The C++ language has always been a programming language, not a
programming language + build specification + anything else.
To achieve the zero-overhead principle C++ assumes a very compact object
model, in which no redirection shall be needed unless otherwise
specified. The P-impl method is the kind of redirection in data
structure the language refuses to construct itself. The "unless
otherwise specified" is the virtual function part.
In any case, a non p-impl design constitute a clean design provided you
are happy to recompile the entire program every time you make a little
bit of change here and there.
Problem 2) and 3) are entirely design problems and are only problems to
certain type of situations. Obviously, the language does not enforce them.
You really can define public interface and the rest of the class in
separate files in C++. Yes, you can, without doing p-impl or
inheritance. But then it is just a way to organise the program and it
still doesn't solve problems 1) 2) and 3).
Regards,
B.
Ben