Re: A[x][y][z]



sterten@xxxxxxx writes:
> it's awful in C with multi-dimension arrays.

I don't disagree.

C doesn't actually have multi-dimensional arrays. It only has
one-dimensional arrays, but the element type can itself be an array
type; an array of arrays of arrays acts very much like a 3-dimensional
array.

> A[x][y][z] is worse than A[x,y,z] ,

It's fine once you get used to it. Note also that A[x,y,z] is also a
valid expression (though not one that you'd ever want to use). The
comma operator evaluates both operands and yields the result of its
right operand, so A[x,y,z] is equivalent to A[z] (assuming x and y
have no side effects).

And because of the relationship between arrays and pointers, the
actual meaning of A[x][y][z] can vary depending on whether A is an
array of arrays of arrays, or a pointer to an array of pointers to
arrays of pointers to arrays (I think I got that right), or any of a
number of other possibilities. The pointer implementation is actually
more common because it's more flexible.

> is someone successfully running the C-compiler from batch-file,
> first converting all of the latter expressions
> into the corresponding former ones and then compiling it ?

I sincerely hope not.

> And while we're at it, this preprocessing utility should
> also change array definitions like e.g.
> int B[N];
> into int B[N+1];
> since B[N] would not be defined else, only B[0],B[1],..,B[N-1]

And while you're at it, you can do things like:

#define IF if(
#define THEN ){
#define ELSE }else{
#define ELSEIF }else if(
#define ENDIF }

and pretend you're writing in a different language altogether. Except
that you're still really programming in C, with all the drawbacks that
implies, with a thin and fragile layer of a different syntax on top of
it.

People have tried this kind of thing, and it's invariably a bad idea.
The result is something that experienced C programmers won't be able
to read because it doesn't look like C, and experienced programmers in
other languages won't be able to read because it doesn't quite look
like anything else.

There is an underlying logic to the way C is designed. You might not
like it (there are things I dislike myself), but you really should try
to understand it before you try to mess with it.

If you want to program in C, you should learn C, with all its little
quirks. If you dislike C so much, you should pick a different
language.

--
Keith Thompson (The_Other_Keith) kst-u@xxxxxxx <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
.



Relevant Pages

  • Re: Array comparison
    ... > Deep and recursive. ... the pointers and comparing their referents instead of comparing the ... >> arrays, then I think you also need to argue against assigning arrays. ... semantics (notably, reference counting). ...
    (alt.comp.lang.borland-delphi)
  • Re: double pointer
    ... Nor is it up to me, Deitel 1, Deitel 2, Schildt, ... that arrays are pointers, or that pointers are arrays, in C++. ...
    (comp.lang.c)
  • Re: Doubt about arrays name
    ... basicly pointers are arrays and arrays are pointers, ... but "int main" is better. ... In this case, for traversing a string, using int can't ...
    (comp.lang.c)
  • Re: new IL: C (sort of...).
    ... about the fact that in PIC's C you can't have arrays larger than 256 bytes. ... Its pointers are rudimentary) Its semantics are rather Delphi than C. ... This goes nearly for any static compiled imperative language. ... result of some minor memory saving in the original compiler or to its funky ...
    (comp.lang.misc)
  • Re: low-level pointer vs. array question
    ... arrays, I was not aware of this: ... pointers and arrays, ... it is indeed a platform (and compiler) ...
    (comp.lang.c)