Earlier quoted context omitted.
A simple case is hiding the implementation and exposing a public API. Let's use objects to make it something C++ ought to be good at and C ought to be bad at. In C, you write a header file adder.h: struct Adder; struct Adder *adder_create(void); void adder_setup(struct Adder *, int, int); int adder_operate(struct Adder *); void adder_delete(struct Adder *); You can easily imagine how one would trivially implement the…
About your two realizations: 1. I've "exposed" parts of the private implementation in that they were in the header file, yes. They were also labeled "private". That means that someone can read that and gain more information about my implementation then they could from just public information, I suppose. It also means that nobody can actually use them in code, because they're private . So you can think of that as "exp…
Surely problems are always personal, this all did start with the term "pet peeve".
For me, one of the peeves that comes back over and over is indeed that it seems that's near impossible to write a separation between the API and the implementation in C++ that is clean and beautiful. That's one of the first things in any project, drafting out the interfaces. And things get ugly quick there.
There are others but I drafted this particular case as an example that you requested. I don't want to go too deep into the discussion here but I'll reply to the two points below:
1) Exposing fields and functions under the private label is just a matter of principle. It doesn't matter if the private parts cannot technically be used outside the class: it still means there is information in the public API that shouldn't have to be there in the first place. That's just a stupid restriction of quirky language. A header file is mainly about the interface and its documentation: the last thing I want in it is to have cluttering bits of internal crap there only to be skipped over.
I could also cram all the code in a single source file and use global variables because hey, it can be made to work and it's easier to write a linker that way. The same applies with the public interface issue here.
2) Check back my C header file again. The struct layout is only visible to the implementation. As long as the ABI stays the same we can even use a different compiler to build the private implementation into a binary and the interface still works with all existing code.
Yet this is still about the fact that the private bits do not have to be visible to the public, just the implementation. So the language that forces me to do just that for the sake of convenience for the language designer and compiler writers is just plain stupid.