[...]
It could support the concept of information hiding. That a
derived class doesn't have to know or care about private parts
of a base class. Which is fairly important, and supported by
other languages.
Yes. Although the support does vary.
The problem is that both access control and visibility control
are valid concepts, in themselves. For whatever historical
reasons, C++ choose the first. This means that declaring
something private does NOT mean that clients can ignore it.
Sometimes, in fact, the fact that something is declared private
is actually part of the public interface, e.g. the presence of a
private copy constructor or assignment operator definitely
changes the interface available to the client, and it is common
to declare virtual functions (including pure virtual functions)
private in order to implement programming by contract.
But of course, the fact that we get these benefits means that
there are other benefits we don't get, and as Alf says,
encapsulation takes a serious blow.
Java, I think, mixes them, but private is very definitely
visibility, and not access. The result is, of course, that in
order to implement programming by contract, you have to use
protected virtual functions, rather than private. (Of course,
the real problem is that you can't do this in an interface, only
in an abstract class, which means that you loose multiple
inheritence.)
In C++ the only real way to achieve information hiding is to
use the PIMPL idiom.
Which drags in several costs -- complexity, physical
packaging, efficiency -- when the C++ golden rule is "no
unnecessary abstraction cost" (of course, after the "don't pay
for what you don't use" principle, but still). As I recall
the argument for not supporting information hiding in C++ was
that it would require opaque types à la Modula-2, where an
opaque type was really just a pointer in disguise, and this
would add an always-there cost for something you'd not always
want to use. But that argument is simply false: information
hiding can be much simpler, because what's important is not
physical hiding but logical, that one shouldn't have to care
about, and that one's code shouldn't be affected by, private
things (this also goes to ability to freely change private
things)...
Part of the arguments were related to providing efficent value
semantics with the classical compiler/linker model. Which
resulted in the private parts not being really private; the
compiler at least had to see them and take them into account.
Beyond that, I do seem to recall some argument along the lines
of changing a function from private to public silently changing
semantics (to which, of course, the answer is: don't do that).
What ever the original reasons, it turns out that there is also
some value in access control, as opposed to visibility control.
How much is, as I said, debatable.
I might add that in the case of function overloading, I really
don't think it should matter. Just don't give functions with
different access the same name.
