Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!cbatt!osu-eddie!osupyr!hrubin
From: hrubin@osupyr.UUCP
Newsgroups: comp.lang.c
Subject: Types
Message-ID: <293@osupyr.UUCP>
Date: Sun, 10-May-87 08:32:09 EDT
Article-I.D.: osupyr.293
Posted: Sun May 10 08:32:09 1987
Date-Received: Wed, 13-May-87 01:48:45 EDT
References: <7264@brl-adm.ARPA> <734@sdchema.sdchem.UUCP>
Organization: Department of Statistics
Lines: 33
Summary: Big changes are needed

In article <734@sdchema.sdchem.UUCP>, tps@sdchem.UUCP (Tom Stockfisch) writes:
> In article <7264@brl-adm.ARPA> lyle@ads.arpa (Lyle Bacon) writes:
> 
> >	C is an evolving language.  I will make a possibly sacrilegious
> >suggestion that the type "complex" be incorporated.
> >	The purest says:" Well, one can just define a structure complex."
> >	...However, the resultant code form using structures and func-
> >tions is much less readable and harder to check....
> >P = complex_mult(A, complex_mult(B, C));
> >
> >P = A * B * C;
> >is more easily read and checked.
> 
> 
> This only solves the problem for the type "complex".  What about vectors
> and matrices and (use your imagination)?

 What we people who can program using the power of the computer really need
to do is convince the X3J11 committee to accept the idea that overloaded
operators, defining of new types (not like C++), defining of operator
symbols corresponding to operations not included in the default language,
forcing inline, substitution of compiler-determined locations in inserted
assembler instructions, and other versatile devices, and in general enabling
the production of good semi-portable code is worthwhile.
-- 
Herman Rubin
Until mid May:
Department of Statistics, Cockins Hall, 1958 Neil Avenue
Ohio State University, Columbus OH43210
hrubin@osupyr or cbosgd!osu-eddie!osupyr!hrubin or ts0474@ohstvma.bitnet
"Permanent":
Department of Statistics, Purdue University, West Lafayette IN47907
hrubin@l.cc.purdue.edu or ihnp4!pur-ee!stat-l!hrubin or hrubin@purccvm.bitnet