🚀 go-pugleaf

> 
> .... I have one question, though: since classes are essentially structs,
> and structs can have member functions and private/public parts, why bother 
> creating separate classes at all? Why not just extend the struct syntax
> with the things you've got for classes - derivation, etc.?

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

Ron Crocker
AT&T Bell Laboratories
Naperville-Wheaton Road
Naperville, IL  60566
(312) 979-4051

Views expressed are mine and not my employers.

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

> 
> Just finished reading bs's book (which is definitely not bs) and enjoyed it 
> very much. I have one question, though: since classes are essentially structs,
> and structs can have member functions and private/public parts, why bother 
> creating separate classes at all? Why not just extend the struct syntax
> with the things you've got for classes - derivation, etc.?

Structs do not have private parts. Other then that the question is
valid, except that I formulate it this way:

Structs are subset of classes. Why to have structs at all and
not to use classes for both and call them structs ?