Comme le souligne Joel dans le podcast Stack Overflow # 34 , en langage de programmation C (alias: K & R), il est fait mention de cette propriété des tableaux en C:a[5] == 5[a]

Joel dit que c'est à cause de l'arithmétique des pointeurs mais je ne comprends toujours pas. Pourquoia[5] == 5[a] ?

La norme C définit l' []opérateur comme suit:

a[b] == *(a + b)

Évaluera donc a[5]:

*(a + 5)

et 5[a]évaluera:

*(5 + a)

aest un pointeur sur le premier élément du tableau. a[5]est la valeur qui est éloignée de 5 élémentsa , ce qui est le même que *(a + 5), et des mathématiques du primaire, nous savons que ceux-ci sont égaux (l'addition est commutative ).

Parce que l'accès aux tableaux est défini en termes de pointeurs. a[i]est défini comme signifiant *(a + i), qui est commutatif.

Je pense que quelque chose manque aux autres réponses.

Oui, p[i]est par définition équivalent à *(p+i), qui (parce que l'addition est commutative) est équivalent à *(i+p), qui (encore une fois, par la définition de l' []opérateur) est équivalent à i[p].

(Et dans array[i], le nom du tableau est implicitement converti en un pointeur vers le premier élément du tableau.)

Mais la commutativité de l'addition n'est pas si évidente dans ce cas.

Lorsque les deux opérandes sont du même type, ou même de différents types numériques qui sont promus à un type commun, commutativité est parfaitement logique: x + y == y + x.

Mais dans ce cas, nous parlons spécifiquement de l'arithmétique des pointeurs, où un opérande est un pointeur et l'autre est un entier. (Entier + entier est une opération différente et pointeur + pointeur est un non-sens.)

La description de l' +opérateur par la norme C ( N1570 6.5.6) dit:

De plus, soit les deux opérandes doivent avoir un type arithmétique, soit un opérande doit être un pointeur vers un type d'objet complet et l'autre doit avoir un type entier.

Il aurait tout aussi bien pu dire:

De plus, soit les deux opérandes doivent être de type arithmétique, soit l' opérande de gauche doit être un pointeur vers un type d'objet complet et l' opérande de droite doit avoir un type entier.

auquel cas les deux i + pet i[p]seraient illégaux.

En termes C ++, nous avons vraiment deux ensembles d' +opérateurs surchargés , qui peuvent être décrits de manière générale comme:

pointer operator+(pointer p, integer i);

et

pointer operator+(integer i, pointer p);

dont seul le premier est vraiment nécessaire.

Alors pourquoi est-ce ainsi?

C ++ a hérité de cette définition de C, qui l'a obtenue de B (la commutativité de l'indexation de tableaux est explicitement mentionnée dans la référence des utilisateurs de 1972 à B ), qui l'a obtenue de BCPL (manuel daté de 1967), qui pourrait bien l'avoir obtenue de même langues antérieures (CPL? Algol?).

Ainsi, l'idée que l'indexation de tableaux est définie en termes d'addition, et que l'addition, même d'un pointeur et d'un entier, est commutative, remonte à plusieurs décennies, aux langages des ancêtres de C.

Ces langages étaient beaucoup moins fortement typés que le C moderne. En particulier, la distinction entre pointeurs et entiers a souvent été ignorée. (Les premiers programmeurs C utilisaient parfois des pointeurs comme des entiers non signés, avant que le unsignedmot - clé ne soit ajouté au langage.) Ainsi, l'idée de rendre l'addition non commutative parce que les opérandes sont de types différents n'aurait probablement pas surgi pour les concepteurs de ces langages. Si un utilisateur voulait ajouter deux "choses", que ces "choses" soient des entiers, des pointeurs ou autre chose, ce n'était pas à la langue de l'empêcher.

Et au fil des ans, toute modification de cette règle aurait violé le code existant (bien que la norme ANSI C de 1989 ait pu être une bonne opportunité).

Changer C et / ou C ++ pour exiger de placer le pointeur à gauche et l'entier à droite pourrait casser du code existant, mais il n'y aurait aucune perte de puissance expressive réelle.

Nous avons donc maintenant arr[3]et 3[arr]signifiant exactement la même chose, bien que cette dernière forme ne devrait jamais apparaître en dehors de l' IOCCC .

Et bien sûr

 ("ABCD"[2] == 2["ABCD"]) && (2["ABCD"] == 'C') && ("ABCD"[2] == 'C')

La principale raison en était que dans les années 70, lorsque C a été conçu, les ordinateurs n'avaient pas beaucoup de mémoire (64 Ko, c'était beaucoup), donc le compilateur C ne faisait pas beaucoup de vérification de la syntaxe. Par conséquent, " X[Y]" a été traduit aveuglément en " *(X+Y)"

Cela explique également les syntaxes " +=" et " ++". Tout sous la forme " A = B + C" avait la même forme compilée. Mais, si B était le même objet que A, alors une optimisation au niveau de l'assemblage était disponible. Mais le compilateur n'était pas assez brillant pour le reconnaître, donc le développeur a dû ( A += C). De même, si Cc'était le cas 1, une optimisation de niveau d'assemblage différente était disponible, et encore une fois, le développeur devait la rendre explicite, car le compilateur ne l'a pas reconnue. (Plus récemment, les compilateurs le font, donc ces syntaxes sont largement inutiles de nos jours)

Personne ne semble avoir mentionné le problème de Dinah avec sizeof :

Vous ne pouvez ajouter qu'un entier à un pointeur, vous ne pouvez pas ajouter deux pointeurs ensemble. De cette façon, lors de l'ajout d'un pointeur à un entier ou d'un entier à un pointeur, le compilateur sait toujours quel bit a une taille qui doit être prise en compte.

Pour répondre à la question littéralement. Il n'est pas toujours vrai quex == x

double zero = 0.0;
double a[] = { 0,0,0,0,0, zero/zero}; // NaN
cout << (a[5] == 5[a] ? "true" : "false") << endl;

impressions

false

Je viens de découvrir que cette syntaxe laide pourrait être "utile", ou du moins très amusante à jouer avec un tableau d'index qui fait référence à des positions dans le même tableau. Il peut remplacer les crochets imbriqués et rendre le code plus lisible!

int a[] = { 2 , 3 , 3 , 2 , 4 };
int s = sizeof a / sizeof *a;  //  s == 5

for(int i = 0 ; i < s ; ++i) {  

           cout << a[a[a[i]]] << endl;
           // ... is equivalent to ... 
           cout << i[a][a][a] << endl;  // but I prefer this one, it's easier to increase the level of indirection (without loop)

}

Bien sûr, je suis sûr qu'il n'y a pas de cas d'utilisation pour cela dans du vrai code, mais je l'ai quand même trouvé intéressant :)

Belles questions / réponses.

Je veux juste souligner que les pointeurs et les tableaux C ne sont pas les mêmes , bien que dans ce cas la différence ne soit pas essentielle.

Considérez les déclarations suivantes:

int a[10];
int* p = a;

Dans a.out, le symbole se atrouve à une adresse qui est le début du tableau, et le symbole se ptrouve à une adresse où un pointeur est stocké, et la valeur du pointeur à cet emplacement de mémoire est le début du tableau.

Pour les pointeurs en C, nous avons

a[5] == *(a + 5)

et aussi

5[a] == *(5 + a)

Il est donc vrai que a[5] == 5[a].

Pas une réponse, mais juste quelques pistes de réflexion. Si la classe a un opérateur d'index / indice surchargé, l'expression 0[x]ne fonctionnera pas:

class Sub
{
public:
    int operator [](size_t nIndex)
    {
        return 0;
    }   
};

int main()
{
    Sub s;
    s[0];
    0[s]; // ERROR 
}

Puisque nous n'avons pas accès à la classe int , cela ne peut pas être fait:

class int
{
   int operator[](const Sub&);
};

Il a une très bonne explication dans A TUTORIAL ON POINTERS AND ARRAYS IN C de Ted Jensen.

Ted Jensen l'a expliqué comme suit:

En fait, cela est vrai, c'est-à-dire que partout où l'on écrit, a[i]il peut être remplacé *(a + i) sans problème. En fait, le compilateur créera le même code dans les deux cas. Ainsi, nous voyons que l'arithmétique des pointeurs est la même chose que l'indexation des tableaux. L'une ou l'autre syntaxe produit le même résultat.

Cela ne veut PAS dire que les pointeurs et les tableaux sont la même chose, ils ne le sont pas. Nous disons seulement que pour identifier un élément donné d'un tableau, nous avons le choix entre deux syntaxes, l'une utilisant l'indexation des tableaux et l'autre utilisant l'arithmétique des pointeurs, qui donnent des résultats identiques.

Maintenant, en regardant cette dernière expression, en partie .. (a + i), est un simple ajout en utilisant l'opérateur + et les règles de C indiquent qu'une telle expression est commutative. C'est-à-dire que (a + i) est identique à (i + a). Ainsi, nous pourrions écrire *(i + a)aussi facilement que *(a + i). Mais *(i + a)aurait pu venir i[a]! De tout cela vient la curieuse vérité que si:

char a[20];

l'écriture

a[3] = 'x';

revient à écrire

3[a] = 'x';

Je sais qu'on a répondu à la question, mais je n'ai pas pu résister à partager cette explication.

Je me souviens des principes de conception du compilateur, supposons aqu'un inttableau ait une taille de int2 octets et que l'adresse de base asoit 1000.

Comment ça a[5]va marcher ->

Base Address of your Array a + (5*size of(data type for array a))
i.e. 1000 + (5*2) = 1010

Donc,

De même, lorsque le code c est décomposé en code à 3 adresses, 5[a]deviendra ->

Base Address of your Array a + (size of(data type for array a)*5)
i.e. 1000 + (2*5) = 1010 

Donc , fondamentalement , les deux déclarations pointent vers le même emplacement en mémoire et , par conséquent, a[5] = 5[a].

Cette explication est également la raison pour laquelle les indices négatifs dans les tableaux fonctionnent en C.

c'est-à-dire que si j'y accède, a[-5]cela me donnera

Base Address of your Array a + (-5 * size of(data type for array a))
i.e. 1000 + (-5*2) = 990

Il me rendra l'objet à l'emplacement 990.

Dans les tableaux C , arr[3]et 3[arr]sont les mêmes, et leurs notations de pointeur équivalentes sont *(arr + 3)à *(3 + arr). Mais au contraire [arr]3ou [3]arrn'est pas correct et entraînera une erreur de syntaxe, car (arr + 3)*et (3 + arr)*ne sont pas des expressions valides. La raison en est que l'opérateur de déréférencement doit être placé avant l'adresse fournie par l'expression, et non après l'adresse.

dans le compilateur c

a[i]
i[a]
*(a+i)

sont différentes façons de faire référence à un élément d'un tableau! (PAS DU tout bizarre)

Un peu d'histoire maintenant. Entre autres langages, BCPL a eu une influence assez importante sur le développement précoce de C. Si vous avez déclaré un tableau dans BCPL avec quelque chose comme:

let V = vec 10

qui allouait en fait 11 mots de mémoire, pas 10. Typiquement, V était le premier et contenait l'adresse du mot immédiatement suivant. Donc, contrairement à C, nommer V est allé à cet endroit et a pris l'adresse du zéro élément du tableau. Par conséquent, l'indirection de tableau dans BCPL, exprimée en

let J = V!5

vraiment à faire J = !(V + 5)(en utilisant la syntaxe BCPL) car il était nécessaire de récupérer V pour obtenir l'adresse de base du tableau. Ainsi V!5et5!V étaient synonymes. Comme observation anecdotique, le WAFL (Warwick Functional Language) a été écrit en BCPL, et au mieux de ma mémoire avait tendance à utiliser cette dernière syntaxe plutôt que la première pour accéder aux nœuds utilisés comme stockage de données. Certes, cela remonte à environ 35 à 40 ans, donc ma mémoire est un peu rouillée. :)

L'innovation de supprimer le mot de stockage supplémentaire et de demander au compilateur d'insérer l'adresse de base de la baie quand il a été nommé est venue plus tard. Selon le journal d'histoire C, cela s'est produit à peu près au moment où les structures ont été ajoutées à C.

Notez que !dans BCPL était à la fois un opérateur de préfixe unaire et un opérateur d'infixe binaire, dans les deux cas faisant de l'indirection. juste que la forme binaire incluait un ajout des deux opérandes avant de faire l'indirection. Étant donné la nature orientée mot de BCPL (et B), cela avait en fait beaucoup de sens. La restriction du "pointeur et entier" a été rendue nécessaire en C quand il a gagné des types de données, et sizeofest devenue une chose.

Eh bien, c'est une fonctionnalité qui n'est possible qu'en raison de la prise en charge des langues.

Le compilateur interprète a[i]comme *(a+i)et l'expression est 5[a]évaluée *(5+a). Puisque l'addition est commutative, il s'avère que les deux sont égaux. Par conséquent, l'expression est évaluée à true.

En C

 int a[]={10,20,30,40,50};
 int *p=a;
 printf("%d\n",*p++);//output will be 10
 printf("%d\n",*a++);//will give an error

Le pointeur est une "variable"

le nom du tableau est un "mnémonique" ou un "synonyme"

p++;est valide mais a++n'est pas valide

a[2] est égal à 2 [a] parce que le fonctionnement interne sur les deux est

"Arithmétique du pointeur" calculée en interne comme

*(a+3) équivaut à *(3+a)

types de pointeurs

1) pointeur vers les données

int *ptr;

2) pointeur const vers les données

int const *ptr;

3) pointeur const vers les données const

int const *const ptr;

et les tableaux sont de type (2) de notre liste
Lorsque vous définissez un tableau à la fois, une adresse est initialisée dans ce pointeur
Comme nous savons que nous ne pouvons pas changer ou modifier la valeur de const dans notre programme car cela déclenche une ERREUR lors de la compilation temps

La principale différence que j'ai trouvée est ...

On peut réinitialiser le pointeur par une adresse mais pas le même cas avec un tableau.

======
et revenons à votre question ...
a[5]n'est rien mais *(a + 5)
vous pouvez facilement comprendre en
a - contenant l'adresse (les gens l'appellent comme adresse de base) tout comme un type de pointeur (2) dans notre liste
[]- cet opérateur peut être remplaçable par un pointeur *.

donc finalement ...

a[5] == *(a +5) == *(5 + a) == 5[a]