stt@spock.camb.inmet.com (Tucker Taft) writes:
|It would be very useful to allow private static member
|functions to be declared outside the class declaration.
|For example:
|      private static void C::helper(C* p)
|      {
|           /* This function does something useful */
|           /* that depends on access to private members of C */
|      }
|Such a declaration would be visible within its file only, and
|only to other member functions of the same class (or their
|friends in the same file).
|
|This could dramatically reduce recompilation problems
|in environments where any change to a ".h" causes massive
|recompilation.

Since you're only asking for this for static member functions,
you can get pretty much the same effect in the existing language,
by using a friend class.

   class C {
      // ...
      friend class FriendOfC;
   };

Put the static member functions in FriendOfC instead of C; then
you can add or remove functions without forcing the users of C
to recompile.

--
Patrick Smith
uunet.ca!frumious!pat
pat%frumious.uucp@uunet.ca

In article <1992Nov3.002354.672@frumious.uucp>
uunet.ca!frumious!pat writes:

>stt@spock.camb.inmet.com (Tucker Taft) writes:
>|It would be very useful to allow private static member
>|functions to be declared outside the class declaration.
>|For example:
>|      private static void C::helper(C* p)
>|      {
>|           /* This function does something useful */
>|           /* that depends on access to private members of C */
>|      }
>|Such a declaration would be visible within its file only, and
>|only to other member functions of the same class (or their
>|friends in the same file).
>|
>|This could dramatically reduce recompilation problems
>|in environments where any change to a ".h" causes massive
>|recompilation.
>
>Since you're only asking for this for static member functions,
>you can get pretty much the same effect in the existing language,
>by using a friend class.
>
>   class C {
>      // ...
>      friend class FriendOfC;
>   };
>
>Put the static member functions in FriendOfC instead of C; then
>you can add or remove functions without forcing the users of C
>to recompile.

Neat trick.  But why force every programmer who might someday
want to add a local static private member function to the
implementation of a class to use this trick?  Why
not just make the capability a part of C++, consistent with
good software engineering principles and information hiding?

Other languages that have the concept of a module
recognize that you shouldn't have to declare in the interface
to the module all functions local to the implementation of the
module, just because they see the private declarations of the
module.  In C++, the class is the module, and the class declaration
is its interface.  Forcing all private static member functions to
appear there is a real hindrance to reasonable implementation
modularity.

>Patrick Smith
>uunet.ca!frumious!pat
>pat%frumious.uucp@uunet.ca

S. Tucker Taft  stt@inmet.com
Intermetrics, Inc.
Cambridge, MA  02138

It would be very useful to allow private static member
functions to be declared outside the class declaration.
For example:
      private static void C::helper(C* p)
      {
           /* This function does something useful */
           /* that depends on access to private members of C */
      }
Such a declaration would be visible within its file only, and
only to other member functions of the same class (or their
friends in the same file).

This could dramatically reduce recompilation problems
in environments where any change to a ".h" causes massive
recompilation.  Such private static member functions
are useful to keep the size of the visible member functions
of a class reasonably small.  However, if one must broadcast
everytime such a new private static member function is added,
the incentive will be to just make the visible member bigger,
copying code rather than sharing it between member functions
of the same class, etc.

This does not open any access "holes" because such a
"local" private static member can only be reached through
some "global" member function.  It is just a way to
carve off some shared functionality into a separate function,
something that a class implementor/maintainer should be able
to do without disturbing any clients of the class.

There was a recent flurry about completely omitting the private
part from a class declaration.  This doesn't work too well
for non-function members because it interferes with compile-time
size determination.  This is a surmountable problem, but typically
requires some implicit level of indirection and an extra
mark/release stack (any language that allows local variables
of compile-time-unknown size already solves this problem,
e.g. Algol 60 did it 32 years ago, but it does introduce
overhead and complexity).  It gets worse when you have
instances of such classes as members of other classes -- the
dynamicity of size spreads.

On the other hand, there is no implementation-related need
to require that the declaration of private static member
functions appear in a globally visible place.  This has been
pointed out in the past, and one justification for the requirement
has been that the existence of such functions is somehow
part of the "abstraction."  This seems like a pretty
weak argument (there may be other stronger arguments, but
I am not aware of them).

S. Tucker Taft   stt@inmet.com
Intermetrics, Inc.
Cambridge, MA  02138