Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!ukc!dcl-cs!aber-cs!athene!pcg
From: pcg@cs.aber.ac.uk (Piercarlo Grandi)
Newsgroups: comp.lang.c++
Subject: Re: C++, Object Design Methodologies and Software Engineering
Message-ID: <PCG.90Nov4190329@athene.cs.aber.ac.uk>
Date: 4 Nov 90 19:03:29 GMT
References: <24872@uflorida.cis.ufl.EDU> <2390@lupine.NCD.COM>
Sender: pcg@aber-cs.UUCP
Followup-To: comp.lang.c++
Organization: Coleg Prifysgol Cymru
Lines: 72
In-reply-to: rfg@NCD.COM's message of 3 Nov 90 04:15:50 GMT

On 3 Nov 90 04:15:50 GMT, rfg@NCD.COM (Ron Guilmette) said:

rfg> Specifically, I think that the kind of thing that you are perhaps
rfg> looking for might be a header file that looks kinda like this:

rfg> 	class car;
rfg> 	/* void */	car::car (int cost);
rfg> 	/* void */	car::~car ();
rfg> 	heading 	car::turn (direction d);
rfg> 	next_date	car::change_oil (station s);

You can well do this currently with a little sleight of hand using
inheritance. The key to understanding thsi is that your proposal only
works if you manipulate only pointers or references to car objects, and
not for all operations (all that imply dereferencing are out).

Otherwise you have to pull in the full declaration.

rfg> In other words, a sort of *abbreviated* description of the interface to
rfg> a class which is provided to some user of the class.

Also, if my modest proposal for an alternative to member functions
(including destructors and constructors) were allowed, you would write:

 	class car;

 	void		operator { (car &self,int cost); // constructor
 	void		operator } (car &self); // destructor
 	heading		turn (car &self,direction d);
 	next_date	change_oil (car &self,station s);

Then you could write (references are implemented with pointers):

	class car;			typedef struct char char;
	car *c1 = new car(8999);	car *c1 = (car *) malloc(sizeof (car));
					__op_lbrace__car__int(c1,8999);
	c1->turn(90);			__turn__car__direction(c1,90);
	change_oil(*c1,esso);		__change_oil__car__station(c1,esso);
	delete c1;			__op_rbrace__car(c1);
					free((void *) c1);

But please note the problem in the first line; we do not know the value
of sizeof (car). The description is too abbreviated for that:
	
rfg> Allowing abbreviated descriptions like this (which leave out
rfg> information about data members) could potentially cut down
rfg> dramatically on the amount of recompilations we have to do over the
rfg> lifetime of a class.

Precisely -- but this is only because you are going to use pointers for
access. Just like opaque types in Modula 2. And note that without
knowing the size of a car object you cannot even allocate them.

I know of some languages in which to get around this problem and
minimize recompilation and favour binary compatibility across
struct declaration revisions you can say something like

	class[100] car; // car is not more than 100 bytes long
	class[100] { char *make; long unsigned serialno; ... } car;

This has the effect of wasting some space, but avoiding recompilation of
code if one only adds news fields, as long as the total size does not
grow beyond 100 bytes.

Naturally you can go the Ada way and assume that definitions are
precompiled, and by saying just 'import car;' the definition of car is
imported and you don't need to repeat it. But this is not C++, which
assumes conventional compiler technology.
--
Piercarlo "Peter" Grandi           | ARPA: pcg%uk.ac.aber.cs@nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth        | UUCP: ...!mcsun!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk