🚀 go-pugleaf

In article <259400003@inmet> stt@inmet.inmet.com writes:
+
+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.
+
+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).

Just to clarify, I believe that Tucker is misreading E&S to say that the
names of static member functions are not inherited.  As I understand it,
they are.  So I think that my observation is still valid, i.e. that an
extension to C++ to allow the declaration of class member functions *after*
the class type specification is a potentially useful extension, but it
*must* be subject to the restriction that the (added) member functions
must be non-virtual.

-- 

// Ron Guilmette  -  C++ Entomologist
// Internet: rfg@ncd.com      uucp: ...uunet!lupine!rfg
// Motto:  If it sticks, force it.  If it breaks, it needed replacing anyway.