Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site cecil.UUCP
Path: utzoo!watmath!clyde!bonnie!akgua!gatech!ut-sally!seismo!elsie!cecil!keith
From: keith@cecil.UUCP (keith gorlen)
Newsgroups: net.lang
Subject: Re: C++ help needed
Message-ID: <47@cecil.UUCP>
Date: Sun, 1-Dec-85 12:39:38 EST
Article-I.D.: cecil.47
Posted: Sun Dec  1 12:39:38 1985
Date-Received: Tue, 3-Dec-85 07:28:44 EST
References: <188@sdcc7.UUCP>, <1151@ulysses.UUCP>
Organization: NIH-CSL, Bethesda, MD
Lines: 107

>> I need a few answers to some C++ questions.  But first, a bug.
>> This code does not compile.  Moving class inner outside of class outer
>> will cause the thing to compile normally.
>> 
>>   class outer {
>>     class inner {
>>       int inner_data;
>>     };
>>     int outer_data;
>>   public:
>>     int inner_val(inner*);
>>   };
>> 
>>   int outer::inner_val(inner *x) {	// :: was .
>>     return x->inner_data;
>>   };

>This is not a bug.  Nested class declarations are not in the language.
>(But note that an object of one class can be a member of another
>class).  Even if they were in the language, this code would still be

From "Differences between C++ Release E and the AT&T C++ Translator,
release 1.0":

	If a class definition appears inside of another class definition,
	the inner class definition is at the same scope as the outer class
	definition.  The following code is now legal:

		class outer {
			class inner {
			/* ... */
			} x;
		};
		inner y;

Thus it would appear that the latest release of C++ does have nested class
definition, but it can't be used as in the first example.

>C++ is a dandy language, but there is no magic in it.  Also, C++ is an
>extension of C, so certain options are not open.  For example, if you
>have a class X, and you declare an automatic variable of type X, the
>compiler allocates space for it on the stack.  That means the compiler
>has to know the size of objects of type X.  In some other language, you
>might call a function that allocates an object of type X in the free
>store, and returns a pointer to it, and put the pointer on the stack.
>Very well, but that's not C++.  Inline functions can make code much

It seems to me that C++ can do both fairly well:

	class X { ... };

	main() {
		X a;		/* a is an object of class X */
		X& b = *new X;	/* b is a reference (pointer) to an object of
				class X allocated in the free store */

The only problem is that you must remember to delete b when you are done
using it.

>Your task is easiest if you are willing to recompile to change tree
>types.  Then you might supply a different header file for each tree
>type.  Each header file could contain a declaration of class Treenode
>(for example) and the public functions for manipulating Treenodes.  The
>name Treenode and the public functions would be the same for each type
>of tree, but the private data and functions would be different.  If you

A variation on this approach which eliminates the need for re-compilation
(at some cost, of course!) is to have the header file for class Treenode
contain the private data that is common to all types of tree nodes and
"dummy" public virtual function declarations.  Specific types of tree nodes
are implemented as derived classes of Treenode and add data specific to the
node type and implementations of the virtual functions.  The header file
for such a derived class need not be included in any program module that
manipulates only the Treenode abstraction.

>>   Also, when trying to do this sort of thing, I ran across the
>> problem of friend functions that I don't want the user to know
>> about.  For example, a merge function that the member functions
>> call, but which should be private to everyone else.  Is there a way
>> to do this?

>Basically your choices are to tell the user not to look at the private
>parts of your class definitions, or to put all that stuff in a library
>and only hand out object code.  It might be possible to change the
>language and compilation environment so that part of the class
>declaration was available to the compiler but not to the programmer,
>but it's not obvious that the benefits would outweigh the costs.

Another possible solution to this type of problem in C++ is to implement the
merge function as a private member function of a class, then declare the
classes/functions to be permitted to call it as friends.  The big disadvantage
of this is that adding a new class requires adding its name to the list of
friends and re-compilation of everything that uses the class containing the
merge function.

Personally, I don't object to clients being able to look at the private parts
of a class as long as they can't touch them!

-- 
---
	Keith Gorlen
	Computer Systems Laboratory
	Division of Computer Research and Technology
	National Institutes of Health
	Bethesda, MD 20892
	phone:	(301) 496-5363
	uucp:	{decvax!}seismo!elsie!cecil!keith