Should I convert FORTRAN code to C?
Doug Gwyn
gwyn at brl-smoke.ARPA
Fri Jul 1 03:00:08 AEST 1988
In article <148 at quintus.UUCP> ok at quintus.UUCP (Richard A. O'Keefe) writes:
>Maybe I'm confused here, but I thought C only allowed casts to and from
>SCALAR types. In particular, I've never succeeded in casting to or from
>unions or structs.
Well, yes, the two types involved (operand and result) need to be
assignment compatible or the cast operation doesn't even make sense.
How do you assign a 2-D matrix to a 1-D vector?
>Doug Gwyn also claimed that operator overloading wasn't much use, because
>there aren't a lot of uses for it. If your language is APL, maybe not, but
>the arithmetic operations generalise to vectors, matrices, polynomials, &c
>very nicely indeed.
No, they do not. Some of them (e.g. addition) typically have a single
accepted conventional meaning, but others (e.g. multiplication) are not
uniqueley defined. For example, there are at least four "products" of
commensurable vectors that I've had to deal with in the past, the result
of NONE of which is a vector (although two of these result in pseudovectors,
which people who don't know any better often treat as true vectors). Also,
"division" is often ill-defined in extended algebras. Finally, there are
often operators that are more important than the conventional arithmetic
ones.
I know of several cases where treating unsimple data types as having
proerties just like ordinary arithmetic has led to serious errors. (I'm
not even talking about noncommutativity here.) It is much better to
require the designed of an abstract data type to specify the operations
AND for the designer to not use misleading symbols for such operations.
More information about the Comp.lang.c
mailing list