[net.lang.c] Supporting Structure Comparison

tim@unc.UUCP (Tim Maroney) (10/05/83)

Adding structure comparison by means of infix operators to the compiler
would almost certainly be a Big Mistake at this point.  That's not a trivial
problem, and what's more, it will not be particularly effective with respect
to many structures, since so many structures contain pointers and the
"equality" you want to test has nothing to do with the equality of pointers
compared as integers.

What we really want is easy manipulation of complex numbers for all the
number-crunchers out there who will stick to Fortran until C gets complex
numbers with infix operators and high-speed coding of operations (instead of
[god forbid] procedure calls).  The addition of complex numbers is the
sanest idea I've heard yet for extension of C.  There is a particular
problem to be solved, and a simple way to solve it that inarguably increases
the utility of the language.  Further, it shouldn't be too difficult to add
it to any well-organized compiler.

I have come to realize that most language modifications are harmful and
unneeded, but I also know that some are extremely useful.  C has over the
years added many things, most of which are good ideas (structure passing by
value and the void keyword are two recent ones).  I feel fairly strongly
that the addition of the complex data type would be a good thing.

_________________________
Tim Maroney
duke!unc!tim (USENET)
tim.unc@udel-relay (ARPA)

leichter@yale-com.UUCP (Jerry Leichter) (10/05/83)

One more general approach - which I won't either advocate or criticise, for
the moment - has been taken by some compilers (I saw it in some HP compiler):
You allow user-defined operator extensions.  Thus, if a and b are of type
COMPLEX,

	a + b

is compiled as if it was

	SUM_COMPLEX_COMPLEX(a,b)

or some such thing.

To really make this usable for things like complex arithmetic, where I would
want the complex sum to be expanded in line, it should allow SUM_COMPLEX_COMPLEX
to be a macro.  Unfortunately, this would be difficult because of the timing
of macro expansion and expression parsing; the compiler I saw just generated
a function call.

The big question involved in such an approach is:  Can you keep it small and
simple enough to be understandable - and implementable! - while still making
it useful?  As a quick example of the kind of problem you run into, if a is
as above, what should you make of:

	a + 1

If this calls SUM_COMPLEX_int, you'll end up having to write a LOT of functions
just to get things off the ground; if it calls SUM_COMPLEX_COMPLEX, things will
get very confused.
							-- Jerry
					decvax!yale-comix!leichter leichter@yale

jmc@root44.UUCP (10/12/83)

I would be inclined to support ADA-like overloading of operators with
user-defined functions rather than introducing a complex data type just
so you can apply + - * / == (with all the problems of defining these
functions for complex numbers into a standard, library routines like ldiv
built into the compiler etc etc).

That would be much more difficult than squeezing in complex numbers though
I suspect.

John Collins
	....!vax135!ukc!root44!jmc