Path: utzoo!attcan!uunet!snorkelwacker!apple!hercules!sparkyfs!mckenney
From: mckenney@sparkyfs.istc.sri.com (Paul Mckenney)
Newsgroups: comp.std.c++
Subject: Re: Separate Decl of Private Member Fcn
Summary: Use friend classes
Message-ID: <32616@sparkyfs.istc.sri.com>
Date: 7 Sep 90 18:37:04 GMT
References: <259400001@inmet> <259400005@inmet>
Reply-To: mckenney@perth.itstd.sri.com.UUCP (Paul E. McKenney)
Organization: SRI International, Menlo Park, CA 94025
Lines: 45

In article <259400005@inmet> stt@inmet.inmet.com writes:
>Re: Separate Decl of Private Member Fcn
>> 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.

One way to do this within the current definition of C++ to to use
friend classes rather than friend functions.  For example, in a global
header file (foo.h) to be included everywhere (thus not to be lightly
modified):

	class public_interface
		{
		friend class private_implementation;
	public:
		// public interface
	private:
		// private stuff
		};

In a second file (foo.cc), place the definitions of all member functions.
These member functions may refer to members of class ``private_implementation''.
This file may also have the declaration and definition for your utility
functions, as (probably static) member functions of class
``private_implementation''.  These member functions would have access
to class ``public_interface''s private members via the friend clause.
Note that foo.cc may be freely modified to add, delete, or restructure
the utility member functions in class ``private_implementation'' without
requiring all translation units that include foo.h to be recompiled.

>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.

Please accept my apologies for the misunderstanding.

				Thanx, Paul