Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!bu.edu!inmet!stt
From: stt@inmet.inmet.com
Newsgroups: comp.std.c++
Subject: Re: Separate Decl of Private Member Fcn
Message-ID: <259400003@inmet>
Date: 20 Aug 90 15:00:00 GMT
References: <259400001@inmet>
Lines: 36
Nf-ID: #R:inmet:259400001:inmet:259400003:000:1340
Nf-From: inmet.inmet.com!stt    Aug 20 11:00:00 1990


Re: Separate Decl of Private Member Fcn

I wrote:

>>The obvious solution to the concerns about allowing
>>member functions to be added after the end of the class
>>declaration is to require that they be private and static.
>>This makes them visible only to the other member functions,
>>and prevents "hijacking."

Ron Guilmette wrote:

>I generally agree with Tucker's comments, except that I believe that what
>he probably meant to say was that it should be allowable to add private
>*non-virtual* functions after the end of a class.
>
>I don't see how the static-ness of a member function should be an issue when
>it comes to adding member functions after the end of the class.

I agree than non-virtual would probably be adequate, but not as safe as static.
Static implies non-virtual, but it also prevents
"hijacking" of inherited (though non-virtual) member functions.

Also, making something "private" in C++ does not actually
hide it from derivatives, but rather it makes it "inaccessible"
which is subtly diffferent (see E&S page 240 for discussion of
"access control" vs. "visibility control").

Making it static, on the other hand, makes it only usable
within the class, or with an explicit class qualifier.
It never clashes with names in other classes (see E&S page 181).

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