Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!uwm.edu!wuarchive!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!aplcen!haven!ames!sparkyfs!mckenney
From: mckenney@sparkyfs.istc.sri.com (Paul Mckenney)
Newsgroups: comp.std.c++
Subject: Re: Separate Decl of Private Member Fcn
Message-ID: <32527@sparkyfs.istc.sri.com>
Date: 7 Aug 90 17:50:19 GMT
References: <259400001@inmet>
Reply-To: mckenney@itstd.sri.com (Paul E. McKenney)
Organization: SRI International, Menlo Park, CA 94025
Lines: 41

In article <259400001@inmet> stt@inmet.inmet.com writes:
>
>It seems to be a major maintenance/recompilation headache that any
>private utility function which is to be used to implement
>public member functions must be declared in the class declaration,
>either as a private member function, or as a friend.
> [ . . . ]
>This issue is discussed in E&S 9.3, bottom of page 174, but
>I find the argument unconvincing:
>   "Why can't functions be added to a class after the end
>    of the class declaration?  If this were allowed, a user 
>    could gain access to a class simply by declaring an additional
>    function."
>[ . . . ]  Where is the danger?

The danger is that a programmer could hijack a call that was intended
to invoke a base-class member function:

---- standard_library_stuff.h ----
	class A
		{
		void do_the_A_thing() { ... }
		};

	class B : public A
		{
		void do_the_B_thing() { ... do_the_A_thing(); ... }
		};

---- joe_hacker.c ----
	void B::do_the_A_thing()
		{
		... Pilot, take this member function to Iraq! ...
		}


This hijacking could be hidden deep inside a large, complex system and
be very difficult to find, especially if classes A and B had been thoroughly
debugged and were hence presumed innocent.

						Thanx, Paul