Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: Notesfiles $Revision: 1.7.0.10 $; site ccvaxa
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxn!ihnp4!inuxc!pur-ee!uiucdcs!ccvaxa!aglew
From: aglew@ccvaxa.UUCP
Newsgroups: net.lang.c++
Subject: Re: Structs/classes
Message-ID: <47900003@ccvaxa>
Date: Tue, 4-Mar-86 20:58:00 EST
Article-I.D.: ccvaxa.47900003
Posted: Tue Mar  4 20:58:00 1986
Date-Received: Fri, 7-Mar-86 04:15:33 EST
References: <47900002@ccvaxa>
Lines: 62
Nf-ID: #R:ccvaxa:47900002:ccvaxa:47900003:000:2194
Nf-From: ccvaxa.UUCP!aglew    Mar  4 19:58:00 1986


> /* Written 10:55 am  Mar  3, 1986 by crocker@ihwpt.UUCP  */
> > > ... a post by me about structs vs. classes ...
> 
> "By definition, a struct is simply a class with all members public,
> that is
> 	struct s { ...
> is simply shorthand for
> 	class s { public: ...
> 		
> Structures are used when data hiding is inappropriate."
> 
> By the above definition, a "struct" type is not necessary per se,
> and no one is forcing you to use them.  I think that they add to the
> "compatibility" of C and C++.  By calling something a "class"
> implies the use of the data hiding features; calling something a
> "struct" implies openness.

Let me rephrase: why not have added `private:' and `public:' keywords to a
struct declaration, so that
	struct s { ...
is equivalent to 
	struct s { public: ...
and the new construct
	class s { ...
is simply
	struct s { private: ...

I suspect "class" is used in the tradition of Simula.

I find the lack of a `private:' keyword a bit jarring. I am sure eventually
to want to write large classes where each private component has a 
corresponding public element - actual fields, and the abstract operations
that manipulate that field.
	class c {
		private: data_aspect_1;
		public:  operations_on_data_aspect_1;
		
		private: data_aspect_2;
			 data_aspect_3;
			 /* 2 and 3 together implement abstract aspect A */
		public:  operations_on_abstract_aspect_A;
	}
In C++ I must group all the private aspects together, far away from
the corresponding public operations.
	class c {
		data_aspect_1;
		data_aspect_2;
		data_aspect_3;
	    public:
	        operations_on_data_aspect_1;
		operations_on_abstract_aspect_A;
	}

This strikes me as resembling the situation in Wirth-Standard Pascal, where
VAR declarations had to precede all PROCEDURE and FUNCTION declarations, 
preventing functions from being written next to the data structures they 
manipulated. I say this in the past tense, since most Pascals now permit 
arbitrary ordering and intermixing of LABELs, VARs, PROCEDUREs, FUNCTIONs, 
and CONSTs in a block.

Of course, you could say that I should never write large classes, that they should always be broken down into, or built up from, smaller classes.