Commutativity of operator []

[lwawrzyniak]

Wondering, wondering in hopeless night...

int i;
int sum=0;
int array[5] = {1,2,3,4,5};

for (i=0; i<5; i++) sum += array;
for (i=0; i<5; i++) sum += i[array];

I understand why operator [] is commutative, but I'm curious as to
whether anyone has ever found a practical use for the "index[address]"
notation.

FAQ says: "no useful application outside of the Obfuscated C Contest."

What say you?

Thanks!

 

[Robert Gamble]

Wondering, wondering in hopeless night...

int i;
int sum=0;
int array[5] = {1,2,3,4,5};

for (i=0; i<5; i++) sum += array;
for (i=0; i<5; i++) sum += i[array];

I understand why operator [] is commutative, but I'm curious as to
whether anyone has ever found a practical use for the "index[address]"
notation.

FAQ says: "no useful application outside of the Obfuscated C Contest."

What say you?

Since the two forms are identical and i[array] can always be written as
array (pedant disclaimer: assuming "array" and "i" are not sinister
macros), the only difference would be readability, I do not think there
are any cases where i[array] would be preferred in sane programming.

Robert Gamble

 

[Frederick Gotham]

posted:

I understand why operator [] is commutative, but I'm curious as to
whether anyone has ever found a practical use for the "index[address]"
notation.

You word that as if the "index[address]" notation was formulated for a
specific reason...

I seem it more as a "by-product" of how the C language handles the square
brackets operator. Given the following expression:

a

, it's interpreted EXACTLY as:


*(a + b)

Therefore, you can see how the order doesn't matter -- you could as
easily have written:

*(b + a)


Maybe things get a little fishy though if you start using negative
indexes... not sure.

 

[Richard Heathfield]

(e-mail address removed) said:

Wondering, wondering in hopeless night...

int i;
int sum=0;
int array[5] = {1,2,3,4,5};

for (i=0; i<5; i++) sum += array;
for (i=0; i<5; i++) sum += i[array];

I understand why operator [] is commutative, but I'm curious as to
whether anyone has ever found a practical use for the "index[address]"
notation.

FAQ says: "no useful application outside of the Obfuscated C Contest."

What say you?

This was raised on comp.lang.c a few years ago. Someone or other (I forget
who, I'm afraid) pointed out that if you have a bunch of arrays containing
related data, e.g. char *Name[], int Length[], int Pitch[], int Diameter[],
and, say, int Product, then you might want to write:

DisplayS(hnd, x, y, Product[Name]);
DisplayI(hnd, x, y + 1, Product[Length]);
DisplayI(hnd, x, y + 2, Product[Pitch]);
DisplayI(hnd, x, y + 2, Product[Diameter]);

although why you wouldn't use a struct array in that circumstance is, quite
frankly, beyond me.

 

[Skarmander]

(e-mail address removed) said:

Wondering, wondering in hopeless night...

int i;
int sum=0;
int array[5] = {1,2,3,4,5};

for (i=0; i<5; i++) sum += array;
for (i=0; i<5; i++) sum += i[array];

I understand why operator [] is commutative, but I'm curious as to
whether anyone has ever found a practical use for the "index[address]"
notation.

FAQ says: "no useful application outside of the Obfuscated C Contest."

What say you?

This was raised on comp.lang.c a few years ago. Someone or other (I forget
who, I'm afraid) pointed out that if you have a bunch of arrays containing
related data, e.g. char *Name[], int Length[], int Pitch[], int Diameter[],
and, say, int Product, then you might want to write:

DisplayS(hnd, x, y, Product[Name]);
DisplayI(hnd, x, y + 1, Product[Length]);
DisplayI(hnd, x, y + 2, Product[Pitch]);
DisplayI(hnd, x, y + 2, Product[Diameter]);

although why you wouldn't use a struct array in that circumstance is, quite
frankly, beyond me.

Organizing the data one way or the other could have a performance impact.
Fondling memory in just the right way is all the rage in optimization land
these days.

Although I still don't think that would warrant cute syntax like this. Let's
all keep in mind it works this way and never, ever speak of it again...

Now, anyone want cookies?

S.

 

[lawrence.jones]

I understand why operator [] is commutative, but I'm curious as to
whether anyone has ever found a practical use for the "index[address]"
notation.

The only actual use I've ever seen is when "address" was an expression
involving operators with lower precedence than [] and thus would have
needed to be parenthesized when used in the conventional fashion.
Saving two characters of typing is not sufficient justification for the
resulting obfuscation, in my opinion.

-Larry Jones

You can never really enjoy Sundays because in the back of your
mind you know you have to go to school the next day. -- Calvin

 

[CBFalconer]

(e-mail address removed) said:
.... snip ...

I understand why operator [] is commutative, but I'm curious as
to whether anyone has ever found a practical use for the
"index[address]" notation.

FAQ says: "no useful application outside of the Obfuscated C Contest."

What say you?

This was raised on comp.lang.c a few years ago. Someone or other
(I forget who, I'm afraid) pointed out that if you have a bunch of
arrays containing related data, e.g. char *Name[], int Length[],
int Pitch[], int Diameter[], and, say, int Product, then you might
want to write:

DisplayS(hnd, x, y, Product[Name]);
DisplayI(hnd, x, y + 1, Product[Length]);
DisplayI(hnd, x, y + 2, Product[Pitch]);
DisplayI(hnd, x, y + 2, Product[Diameter]);

although why you wouldn't use a struct array in that circumstance
is, quite frankly, beyond me.

I think the promulgator was me, at least I have been know to
express that opinion.

One reason to use such a format is that the various arrays are
fields in a larger database. This avoids the overhead of accessing
unused fields.

 

[Keith Thompson]

int i;
int sum=0;
int array[5] = {1,2,3,4,5};

for (i=0; i<5; i++) sum += array;
for (i=0; i<5; i++) sum += i[array];

I understand why operator [] is commutative, but I'm curious as to
whether anyone has ever found a practical use for the "index[address]"
notation.

FAQ says: "no useful application outside of the Obfuscated C Contest."

What say you?

The FAQ is exactly right.

 

[Mark McIntyre]

On 23 Jun 2006 07:58:00 -0700, in comp.lang.c ,

I understand why operator [] is commutative, but I'm curious as to
whether anyone has ever found a practical use for the "index[address]"
notation.

I've used it a few times, in cases where it was convenient to have
Index[thing1], Index[thing2] etc etc

FAQ says: "no useful application outside of the Obfuscated C Contest."

It wasnt super-useful, but made the code marginally tidier.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

 

[Simon Biber]

This was raised on comp.lang.c a few years ago. Someone or other (I forget
who, I'm afraid) pointed out that if you have a bunch of arrays containing
related data, e.g. char *Name[], int Length[], int Pitch[], int Diameter[],
and, say, int Product, then you might want to write:

DisplayS(hnd, x, y, Product[Name]);
DisplayI(hnd, x, y + 1, Product[Length]);
DisplayI(hnd, x, y + 2, Product[Pitch]);
DisplayI(hnd, x, y + 2, Product[Diameter]);

although why you wouldn't use a struct array in that circumstance is, quite
frankly, beyond me.

I have no problem with this approach with a bunch of related arrays.
There might be good, valid reasons for laying out the data that way.

However, it's just confusing for later readers of the code, to have to
reverse the array name and the index in the way your code above does.

 

[Richard Heathfield]

Simon Biber said:

This was raised on comp.lang.c a few years ago. Someone or other (I
forget who, I'm afraid) pointed out that if you have a bunch of arrays
containing related data, e.g. char *Name[], int Length[], int Pitch[],
int Diameter[], and, say, int Product, then you might want to write:

DisplayS(hnd, x, y, Product[Name]);
DisplayI(hnd, x, y + 1, Product[Length]);
DisplayI(hnd, x, y + 2, Product[Pitch]);
DisplayI(hnd, x, y + 2, Product[Diameter]);

although why you wouldn't use a struct array in that circumstance is,
quite frankly, beyond me.

I have no problem with this approach with a bunch of related arrays.
There might be good, valid reasons for laying out the data that way.

However, it's just confusing for later readers of the code, to have to
reverse the array name and the index in the way your code above does.

I agree entirely. I think it's a terrible idea!

(Did you spot the bug, by the way?)

 

[Kenneth Brody]

Wondering, wondering in hopeless night...

int i;
int sum=0;
int array[5] = {1,2,3,4,5};

for (i=0; i<5; i++) sum += array;
for (i=0; i<5; i++) sum += i[array];

I understand why operator [] is commutative, but I'm curious as to
whether anyone has ever found a practical use for the "index[address]"
notation.

FAQ says: "no useful application outside of the Obfuscated C Contest."

What say you?

Since the two forms are identical and i[array] can always be written as
array (pedant disclaimer: assuming "array" and "i" are not sinister
macros), the only difference would be readability, I do not think there
are any cases where i[array] would be preferred in sane programming.

Speaking of which, I assume "i++[array]" is valid? (My compiler takes
it, even with warning at max.)

What does "++i[array]" mean? Is it "(++i)[array]" or "++(i[array])"?
(Mine treats it as as the latter. I assume precedence defines it as
such.)

Which leads, of course, to the apparently valid "++i++[array]", which is
the same as "++array[i++]".

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:[email protected]>

 

[Andrew Poelstra]

Wondering, wondering in hopeless night...

int i;
int sum=0;
int array[5] = {1,2,3,4,5};

for (i=0; i<5; i++) sum += array;
for (i=0; i<5; i++) sum += i[array];

I understand why operator [] is commutative, but I'm curious as to
whether anyone has ever found a practical use for the "index[address]"
notation.

FAQ says: "no useful application outside of the Obfuscated C Contest."

What say you?

Since the two forms are identical and i[array] can always be written as
array (pedant disclaimer: assuming "array" and "i" are not sinister
macros), the only difference would be readability, I do not think there
are any cases where i[array] would be preferred in sane programming.

Speaking of which, I assume "i++[array]" is valid? (My compiler takes
it, even with warning at max.)

What does "++i[array]" mean? Is it "(++i)[array]" or "++(i[array])"?
(Mine treats it as as the latter. I assume precedence defines it as
such.)

Which leads, of course, to the apparently valid "++i++[array]", which is
the same as "++array[i++]".

And, since ++i++[array] yields an rvalue, this is also legal:

r[a]+=++i++[a]+-n[a];

where a is an array, and i,r,n are integers.

 

[Dik T. Winter]

> >
> > I understand why operator [] is commutative, but I'm curious as to
> > whether anyone has ever found a practical use for the "index[address]"
> > notation.

>
> The only actual use I've ever seen is when "address" was an expression
> involving operators with lower precedence than [] and thus would have
> needed to be parenthesized when used in the conventional fashion.
> Saving two characters of typing is not sufficient justification for the
> resulting obfuscation, in my opinion.

Of course that was not the justification. That arrays are not first-class
citizens in C is the basic reason. I.e., it is just an accident that did
happen. That is, given a pointer (say 's') and an index (say 'i') it was
easier to define 's' as '*(s + i)' without restrictions, than to go to
elaborate rules about the meaning. Moreover, this would work as well if
's' was an array (think about the rule). Commutativity of the addition
did the rest.

 

[Keith Thompson]

I understand why operator [] is commutative, but I'm curious as to
whether anyone has ever found a practical use for the "index[address]"
notation.

The only actual use I've ever seen is when "address" was an expression
involving operators with lower precedence than [] and thus would have
needed to be parenthesized when used in the conventional fashion.
Saving two characters of typing is not sufficient justification for the
resulting obfuscation, in my opinion.

Of course that was not the justification. That arrays are not first-class
citizens in C is the basic reason. I.e., it is just an accident that did
happen. That is, given a pointer (say 's') and an index (say 'i') it was
easier to define 's' as '*(s + i)' without restrictions, than to go to
elaborate rules about the meaning. Moreover, this would work as well if
's' was an array (think about the rule). Commutativity of the addition
did the rest.

Agreed.

I'll note that addition didn't necessarily have to be made commutative
in this case. C's "+" operator is overloaded; different forms take
different types of arguments (float, double, int, etc.). The form
that adds a pointer and an integer, yielding a pointer, is a special
case, the only one that takes arguments of different types. If the
language had defined pointer+integer but not integer+pointer, then the
[] operator would not be commutative, and index[array] would be
illegal.

This would, in my humble opinion, have been a better design, but of
course that's not what we have.

 

[Simon Biber]

Simon Biber said:

This was raised on comp.lang.c a few years ago. Someone or other (I
forget who, I'm afraid) pointed out that if you have a bunch of arrays
containing related data, e.g. char *Name[], int Length[], int Pitch[],
int Diameter[], and, say, int Product, then you might want to write:

DisplayS(hnd, x, y, Product[Name]);
DisplayI(hnd, x, y + 1, Product[Length]);
DisplayI(hnd, x, y + 2, Product[Pitch]);
DisplayI(hnd, x, y + 2, Product[Diameter]);

although why you wouldn't use a struct array in that circumstance is,
quite frankly, beyond me.

I have no problem with this approach with a bunch of related arrays.
There might be good, valid reasons for laying out the data that way.

However, it's just confusing for later readers of the code, to have to
reverse the array name and the index in the way your code above does.

I agree entirely. I think it's a terrible idea!

(Did you spot the bug, by the way?)

Is it that the pitch and the diameter are displayed on the same line?

 

[Richard Heathfield]

Simon Biber said:

Richard Heathfield wrote:

Is it that the pitch and the diameter are displayed on the same line?

Yes. The copy-paste monster strikes again.

 

[Simon Biber]

Simon Biber said:


Yes. The copy-paste monster strikes again.

That was a quick reply: 3 minutes later!

 

[James Dow Allen]

(e-mail address removed) wrote:

... That arrays are not first-class
citizens in C is the basic reason....
That is, given a pointer (say 's') and an index (say 'i') it was
easier to define 's' as '*(s + i)' without restrictions, than to go to
elaborate rules about the meaning. Moreover, this would work as well if
's' was an array (think about the rule). Commutativity of the addition
did the rest.

Yes, C would lose much elegance if arrays were "first class" as
is so often proposed. (And if you need an array to be first-class,
you can simply enclose it within "struct { }" )

... If the
language had defined pointer+integer but not integer+pointer, then the
[] operator would not be commutative, and index[array] would be
illegal.

What would be the purpose (beyond outlawing a "cute" expression)?
It might create confusion for parsers and macro-writers.
(ptr + int + ptr - ptr) is not unheard of (e.g. we might have just
run index() on one of two similar strings) and you'd be asking us
to worry about associativity.

This would, in my humble opinion, have been a better design, but of
course that's not what we have.

Keith and I have agreed to disagree on C's handling of pointers.
For me, it's the feature that makes C distinctly better and more
elegant
than Pascal, etc.

The FAQ is exactly right.

To put the meaningful variable first,
I sometimes write something like
printf("I move my %c", /* tell him which piece we moved */
moved_piece[type]["KQRBNP"]);

If this is "less readable" it is only because of a prejudice that a
isn't
commutative.

Keith Thompson ...
We must do something. This is something. Therefore, we must do this.

Nothing is better than something like this.

James Dow Allen

 

[Chris Dollin]

(ptr + int + ptr - ptr) is not unheard of

As in "I heard the compiler correctly reported an error for this
expression".