Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: notesfiles
Path: utzoo!watmath!clyde!burl!ulysses!bellcore!decvax!decwrl!pyramid!hplabs!hp-pcd!orstcs!nathan
From: nathan@orstcs.UUCP (nathan)
Newsgroups: net.lang.c++
Subject: further C++ fix opportunities
Message-ID: <34200001@orstcs.UUCP>
Date: Mon, 24-Feb-86 21:32:00 EST
Article-I.D.: orstcs.34200001
Posted: Mon Feb 24 21:32:00 1986
Date-Received: Fri, 28-Feb-86 22:09:50 EST
Organization: Oregon State University - Corvallis, OR
Lines: 88
Nf-ID: #N:orstcs:34200001:000:3390
Nf-From: orstcs!nathan    Feb 24 18:32:00 1986

Comments on C++ opportunities

The advent of a new language is an exciting time.  We each
see areas where we would like development, old pet peeves
to be fixed, features yearning to be added.  A strong
guiding hand (used judiciously) becomes extremely valuable.
It makes the difference between, for instance, C++ and Ada.

With that said, I would like to address an area in which I
hope there is still room for flexibility: re-entrancy. 
Modern C is in fact only partially re-entrant, and the
standard library is (in many routines) not at all.

The only non-re-entrant aspect of C itself is in its handling
of structures  returned from functions.

The problem of returning structures from functions has always
been one of where to put the structure.  It could easily go on
stack, except that the calling routine would have to allocate
space for it; but then if the routine was misdeclared, local
variables of the caller could get trashed.  (In C, this was
something to worry about.)  Steve Johnson, author of "pcc",
"resolved" this by reserving a static structure for the
routine, and returning a pointer to it.

This approach works fine, except that functions which return
structures are not re-entrant any more.  If a function is
called again between the times it assigns the first field
of a return value and time the first caller uses a field of the
returned structure, the first caller may receive trash. 
If such functions find their way into a standard library, it
may become very difficult to write a portable program which
requires re-entrancy.

The "pcc" method is no longer necessary.  Now that each
routine's type is known, space may be allocated for before
the call.  (Is it?)  Another problem, already present, now
becomes evident.  In returning a structure, one assigns to
fields of a local variable, then returns it.  This is copied
into the return-value structure (whether on the stack, or
elsewhere), after which the caller either copies it again
or uses one field.  This extra copying seems unnecessary.
To avoid it, some sort of "self" structure is needed.

I propose three alternatives:
given
	struct ab { int a, b };

1. the "null structure": that is, the following:

	struct ab func() {
		.a = 1;
		.b = 2;
	}		// implicit return, no copying needed

	The problem I see with this is twofold; first, what do you call
	the whole structure?  (say I want to pass a pointer to it down
	the line); second, could lint++ (or whatever) cope with such
	a method of returning a value?

2. the function-name structure (ala Pascal):

	struct ab func() {
		func.a = 1; func.b = 2;
		return func;	// type-checking resolves return value
	}

3. The keyword "this" may not be too heavily loaded to take on this
   chore.  A cursory study shows that it is only used now as a pointer:

	struct ab func() {
		this.a = 1; this.b = 2;
		return this;		// explicit return could be optional
	}

   I rather like this last one, though the "&this" problem may remain.

Clearly there are other alternatives.

Whichever method is used, backward compatibility is needed. 
The solution is easy: If a routine returns a pointer to its structure
(wherever it may be), then libraries compiled by the old
method will still work in new programs.

The subject of how to do re-entrant libraries I save for another posting.

	Nathan C. Myers
	{hplabs!hp-pcd | tektronix}!orstcs!nathan OR  nathan@oregon-state