Conformant Arrays in C
Bakul Shah
bvs at light.uucp
Tue Mar 1 08:34:19 AEST 1988
In an earlier article I wrote that multi-dimensional arrays are best
left out of ANSI C and for C++.
Richard A. O'Keefe <ok at quintus.UUCP> responded:
>I am sorry to blaspheme against anyone's religion, but IHMO, C++ itself
>is an unneeded hack. Well, add a smiley to "unneeded", but "hack" I am
>serious about. C++ is the Fortran 8X of object-oriented languages.
> ...
>It is only too credible that conformant array parameters may not be the
>best way of achieving the goals of
> o minimal change to the language and implementation
> o making it straightforward to write functions with multidimensional
> array parameters
> o avoiding over-specification, so that intercallability with other
> language is not impaired more than we can help
>But it is CERTAIN that Bakul Shah's suggested alternatives
>> Why not use C++ or Chris Torek's idea for new code?
>do not meet those goals.
Somewhat different set of goals make sense to me.
1. Avoid any extensions to C at this point -- this would only delay the
the standard. Conformant array parameters or any other means of
making multi-dimensional arrays a first class object would be a major
extension. Leave such extensions to a successor language (I used C++
in this sense, as an *example* -- I don't care to join a discussion
of whether C++ is an abortion or an immaculate conception).
2. A successor language, call it NEXT(C), should first clean up C and
provide a more regular set of features.
3. For NEXT(C) minimal change is not as critical as making all new
features orthogonal (to get maximal use out of a minimal number of
features). Conformant array parameters extension may be *minimal*,
it certainly isn't as orthogonal as some other mechanisms.
4. Do not standardize a new feature until you have implemented and used
it for a few years.
Related topics of
o what KIND of features should go in NEXT(C),
o whether NEXT(C) should be upward compatible to C or a *subset* of C,
o whether NEXT(C) should be a high level assembler (like C) or allow
data abstraction facilities (like CLU does), and,
o whether C++ fits the bill or not
warrant further discussion, separate from this one. I bring up NEXT(c)
mainly to point out that it will be a better language to add MD arrays
(multi-dimensional arrays -- sorry, I can't think of a better name).
In C there ARE some ways of implementing functions that take MD arrays.
They may not be pretty but will get the job done. In my previous article
I used Chris Torek's proposal as an *example*, not as the *right* way to
implement MD arrays. Besides, in a modern language you would want more
than one representation for MD arrays.
BTW, MD arrays in C++ using a variation of Torek's idea is *not* an over-
specification. It is just another piece of useful code, not an extension
to the language. Now if someone proposed legislating it as the only way
to do MD arrays in C++, I would be very surprised and definitely fight it.
Intercallability is not an issue since an MD array can be mapped one-to-
one from one language to another but you will need some glue in some
cases; even Pascal and Fortran are not intercallable without some glue.
But compatibility with Pascal's conformant array parameters can not be a
desirable goal -- conformant arrays are a hack in *any* language!
--
Bakul Shah
..!{ucbvax,sun,py
More information about the Comp.lang.c
mailing list