🚀 go-pugleaf

Re: Separate Decl of Private Member Fcn

McKenney asks:

> So, what does the ability to add member functions after the end of an existing
> class buy you that simply deriving another class from the existing class
> could not?  Especially given the confusion that could result from different
> member functions being independently added to the same class in different
> translation units of the same program...

The point is not really to add new "member functions."  The point
is to allow the implementation of the existing member functions
to use local/static/private "utility" functions which are not 
necessarily visible at all in the class declaration.

C++ nomenclature necessarily considers such
local functions "member functions" (or friends), if they are going to have
any access to the private members of the class, but they are really intended
to serve the same purpose as static functions in C, which
have "file" scope rather than global scope.  By giving such
functions "file" scope, there is no ambiguity if multiple same-named
functions are introduced in distinct files.

If you prefer, these local utility functions could be considered "friends",
but the critical point is that you can add new ones without editing
the class declaration.  The disadvantage of making them friends is that
they would themselves then be accessible to non-members, whereas if they
are private, static members, then only other functions with private access
can call them.

The reference to Ada had nothing to do with derived types.
It was referring to the ability to add local subprograms
to a package body as desired to help in the implementation
of visible subprograms.

S. Tucker Taft
Intermetrics, Inc.
Cambridge, MA  02138