🚀 go-pugleaf

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