[Exceptional C++ Style] Item 16 - (Mostly) Private

[Mark Radford]

Item 16 - (Mostly) Private
--------------------------
The Item is about the extent to which the private parts of a class are 
truly private - or put another way, it's about what "private" actually 
means in this context. It is pointed out, that there are ways for 
private implementation details to leak - some well known and some not so 
well known.

Two themes occur in the Item:

(1) There is a distinction to be drawn between the visibility and 
accessibility of a name. Private members of a class are visible to all 
parties to which the class definition is visible, but their names are 
only accessible to other member functions and friends of the class
(2) Regarding access rights (as opposed to visibility) specifically, 
there is a distinction to be drawn between being allowed to call on a 
member, and being allowed to speak its name. Privacy has a meaning that 
goes beyond calling rights - the name of a private member may be spoken 
only by a class' member functions and friends.

The meaning of theme (1) is highlighted by an example of a class having 
three overloads of the same member function, one public and two private. 
Further, a call by a non-member/non-friend is illustrated, in which the 
best match is one of the private overloads, despite the fact that the 
public overload could be called using a simple and available conversion 
of the argument. The point here is that all member functions - 
regardless of level of access - are considered when the compiler seeks 
candidates for its overload set. The example is then extended to 
illustrate a case where there is no exact mach, but there are two 
candidates - one public and one private - that are satisfactory if a 
simple conversion is applied to the argument. In this case, the error is 
one of an ambiguous call, i.e. the fact that only one satisfactory 
public candidate is available plays no part in resolving which function 
to select (because the compiler builds its overload set before 
considering the level of access).

The meaning of theme (2) is highlighted by an example in which a 
non-member and non-friend of a class attempts to take the address of a 
private member function of the class, and fails - the code won't 
compile. The fact that the non-member/non-friend is not attempting to 
call the function makes no difference - it may not *speak* the name of 
the private member.

The Item goes on to point out that access to a private member can be 
leaked deliberately - i.e. a member function of a class can return a 
pointer to a private member, thus making it accessible to the outside 
world.

Finally, the Item returns to a loophole in C++ language law first 
covered in Item 15. If a class has a member function template, 
specialisations of the template still have access to the class' private 
members. Such specialisations can be written by anyone, and therefore 
member function templates provide users with a back door method of 
accessing the private implementation details. This method is perfectly 
legal and has well defined behaviour.

   - Mark.

-- 
Mark Radford
twoNine Computer Services Ltd - Software Development & Consultancy
http://www.twonine.co.uk