Re: extending c++ classes and enumerations
Greg Herlihy wrote:
[...]
But extending classes in C++ need not break their encapsulation. To
understand why, it is necessary to distinguish between two different
traits that can be used to describe any C++ function. The first is
whether the function is a member of a class interface, and the second
is whether the function's implementation has access to that class's
non-public members. Now the two traits are often conflated (and
treating the two as synonymous leads to a misunderstanding of class
extensions as a feature).
By definition, a member of a class has access to its
implementation. That is the definition of membership.
I've already pointed out that the issue of syntax is not
necessarily a problem, and that at least some experts, in the
past, have suggested some sort of unification with regards to
syntax, so that non-members could use the member syntax and/or
vice versa. If there has been no formal proposal along these
lines, it is doubtlessly because it has been felt unnecessary;
it is trivial to use the non-member syntax for member functions
today (using simple inline forwarding functions), so if it is
felt that some sort of syntax unification is necessary, just
give all of the functions a non-member syntax.
FWIW: his example concerned making std::string "look like" some
other class. I've done this in the past---in pre-standard days,
I (like almost everyone else) had my own string class. When I
moved to std::string, I was bothered by the absense of such
functions as trim and pad, which were present in my pre-standard
string class. The result was simply a set of small, wrapper
functions which implemented them. (See Text/StringUtils at
http://kanze.james.neuf.fr/code-en.html.) It means not using
the member function syntax, but I don't see where that is a
problem.
And the proposal we are responding to did not propose to allow
member function syntax for non-member functions, or vice versa.
It proposed being able to add member functions after the class
has been closed.
The two traits however are independent, and C++ recognizes the
difference even today. After all, a "friend" of a class is one that
possesses the latter trait (access to non-public class members) but
lacks the former one (membership in the class's interface).
A friend is really a type of static member function. The main
difference between a friend function and a static member
function is that the friend function can be found via
unqualified name lookup (more or less important for operator
overloading), and that a function can be friend of several
classes at the same time (although I've never found a use for
this).
Note
further though that the distinction is lopsided: specifically, the
mirror image of the "friend" concept is absent from the C++ language.
The answer to that is that if you want a unified syntax for
members and some non-members, use global function syntax. (But
if you want to propose "relative" functions as an addition to
the standard, I won't jump down your throat. I actually think
that they'd be a slight benefit. Just not enough to be worth
the effort, if I have to do it.)
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientie objet/
Beratung in objektorientierter Datenverarbeitung
9 place Simard, 78210 St.-Cyr-l'Icole, France, +33 (0)1 30 23 00 34
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]