Как указывает Джоэл в подкасте № 34 «Переполнение стека» на языке программирования C (он же K & R), в C упоминается это свойство массивов:a[5] == 5[a]

Джоэл говорит, что это из-за арифметики указателей, но я все еще не понимаю. Почемуa[5] == 5[a] ?

Стандарт C определяет []оператор следующим образом:

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

Поэтому a[5]оценим:

*(a + 5)

и 5[a]будет оценивать:

*(5 + a)

aуказатель на первый элемент массива a[5]это значение, от которого на 5 элементов дальше a, то же самое *(a + 5), и из математики начальной школы мы знаем, что они равны (сложение коммутативно ).

Потому что доступ к массиву определяется с помощью указателей. a[i]определяется, чтобы означать *(a + i), что является коммутативным.

Я думаю, что что-то упускается другими ответами.

Да, p[i]по определению эквивалентно тому *(p+i), что (потому что сложение коммутативно) эквивалентно тому *(i+p), что (опять же, по определению []оператора) эквивалентно i[p].

(И в array[i]этом случае имя массива неявно преобразуется в указатель на первый элемент массива.)

Но коммутативность сложения не так уж очевидна в этом случае.

Когда оба операнда имеют значение того же типа, или даже различных числовых типов, которые способствовали к общему типу, коммутативности имеет смысл: x + y == y + x.

Но в данном случае речь идет именно об арифметике указателей, где один операнд является указателем, а другой - целым числом. (Целое + целое - это другая операция, а указатель + указатель - это нонсенс.)

Описание +оператора в стандарте C ( N1570 6.5.6) гласит:

Кроме того, либо оба операнда должны иметь арифметический тип, либо один операнд должен быть указателем на полный тип объекта, а другой должен иметь целочисленный тип.

С таким же успехом можно было бы сказать:

Кроме того, либо оба операнда должны иметь арифметический тип, либо левый операнд должен быть указателем на полный тип объекта, а правый операнд должен иметь целочисленный тип.

в этом случае оба i + pи i[p]будут незаконными.

В терминах C ++ у нас действительно есть два набора перегруженных +операторов, которые можно условно описать так:

pointer operator+(pointer p, integer i);

а также

pointer operator+(integer i, pointer p);

из которых только первое действительно необходимо.

Так почему же так?

C ++ унаследовал это определение от C, который получил его от B (коммутативность индексации массива явно упоминается в «Справочнике пользователей B» за 1972 г. ), который получил его от BCPL (руководство от 1967 г.), который вполне мог получить его даже от более ранние языки (CPL? Algol?).

Таким образом, идея о том, что индексация массива определяется с точки зрения сложения и что сложение, даже указателя и целого числа, является коммутативной, восходит на многие десятилетия к языкам-предкам Си.

Эти языки были гораздо менее типизированы, чем современные языки. В частности, различие между указателями и целыми числами часто игнорировалось. (Ранние программисты на Си иногда использовали указатели как целые числа без знака до того, как unsignedключевое слово было добавлено к языку.) Поэтому идея сделать добавление некоммутативной, поскольку операнды имеют разные типы, вероятно, не возникла бы у разработчиков этих языков. Если пользователь хотел добавить две «вещи», будь то эти «вещи», являются целыми числами, указателями или чем-то еще, язык не мог предотвратить это.

И на протяжении многих лет любое изменение этого правила нарушало бы существующий код (хотя стандарт ANSI C 1989 года мог бы стать хорошей возможностью).

Изменение C и / или C ++, требующее размещения указателя слева и целого числа справа, может нарушить некоторый существующий код, но при этом не будет потеря реальной выразительной силы.

Так что теперь мы имеем в виду arr[3]и имеем в 3[arr]виду одно и то же, хотя последняя форма никогда не должна появляться за пределами IOCCC .

И, конечно же,

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

Основная причина этого заключалась в том, что еще в 70-х годах, когда разрабатывался C, у компьютеров не было большого количества памяти (64 КБ было много), поэтому компилятор C не делал много проверки синтаксиса. Следовательно, " X[Y]" был довольно слепо переведен на " *(X+Y)"

Это также объясняет синтаксис " +=" и " ++". Все в форме " A = B + C" имеет одинаковую скомпилированную форму. Но если B был тем же объектом, что и A, тогда была доступна оптимизация на уровне сборки. Но компилятор не был достаточно умным, чтобы распознать его, поэтому разработчик должен был ( A += C). Точно так же, если Cбыло 1, была доступна другая оптимизация на уровне сборки, и разработчику снова пришлось сделать это явным, потому что компилятор ее не распознал. (В последнее время это делают компиляторы, поэтому эти синтаксисы сегодня в основном не нужны)

Похоже, никто не упомянул о проблеме Дины с sizeof:

Вы можете добавить только целое число к указателю, вы не можете добавить два указателя вместе. Таким образом, добавляя указатель на целое число или целое число на указатель, компилятор всегда знает, какой бит имеет размер, который необходимо учитывать.

Ответить на вопрос буквально. Это не всегда правда, чтоx == x

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

печать

false

Я просто обнаружил, что этот уродливый синтаксис может быть «полезен» или, по крайней мере, очень забавно играть, когда вы хотите иметь дело с массивом индексов, которые ссылаются на позиции в том же массиве. Он может заменить вложенные квадратные скобки и сделать код более читабельным!

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)

}

Конечно, я вполне уверен, что в реальном коде для этого нет смысла, но я все равно нашел это интересным :)

Хороший вопрос / ответы.

Сразу хочу отметить, что указатели и массивы C не совпадают , хотя в этом случае разница несущественна.

Рассмотрим следующие объявления:

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

В a.out, символ aнаходится по адресу, который является началом массива, и символ pнаходится по адресу, где хранится указатель, а значение указателя в этой ячейке памяти является началом массива.

Для указателей в C мы имеем

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

а также

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

Следовательно, это правда, что a[5] == 5[a].

Не ответ, а просто пища для размышлений. Если в классе перегружен оператор index / subscript, выражение 0[x]не будет работать:

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

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

Поскольку у нас нет доступа к классу int , это невозможно сделать:

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

У него очень хорошее объяснение в «Учебнике по указателям и массивам в Си » Теда Дженсена.

Тед Дженсен объяснил это так:

На самом деле это действительно так, то есть везде, где пишут, a[i]можно *(a + i) без проблем заменить . Фактически, компилятор создаст один и тот же код в любом случае. Таким образом, мы видим, что арифметика указателей - это то же самое, что индексирование массива. Любой синтаксис дает одинаковый результат.

Это НЕ говорит, что указатели и массивы - это одно и то же, но это не так. Мы только говорим, что для идентификации данного элемента массива у нас есть выбор из двух синтаксисов, один из которых использует индексирование массива, а другой - арифметику указателей, которые дают идентичные результаты.

Теперь, глядя на это последнее выражение, его часть .. (a + i), это простое дополнение, использующее оператор + и правила C утверждают, что такое выражение коммутативно. То есть (+ я) идентичен (i + a). Таким образом, мы могли бы написать *(i + a)так же легко, как *(a + i). Но *(i + a)мог прийти i[a]! Из всего этого вытекает любопытная правда, что если:

char a[20];

письмо

a[3] = 'x';

так же, как написание

3[a] = 'x';

Я знаю, что на вопрос дан ответ, но я не удержался, чтобы поделиться этим объяснением.

Я помню Принципы разработки компилятора. Предположим, aэто intмассив и размер int2 байта, а базовый адрес для a1000.

Как a[5]будет работать ->

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

Так,

Точно так же, когда код c разбит на 3-адресный код, 5[a]станет ->

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

Таким образом , в основном оба заявления указывают на то же место в памяти и , следовательно, a[5] = 5[a].

Это объяснение также является причиной, по которой отрицательные индексы в массивах работают в C.

то есть, если я получу доступ, a[-5]это даст мне

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

Он вернет мне объект в локации 990.

В массивах С , arr[3]и 3[arr]одни и те же, и их эквивалентные обозначения указателей являются *(arr + 3)для *(3 + arr). Но наоборот [arr]3или [3]arrне правильно и приведет к синтаксической ошибке, так как (arr + 3)*и (3 + arr)*не являются допустимыми выражениями. Причина в том, что оператор разыменования должен быть помещен перед адресом, полученным выражением, а не после адреса.

в компиляторе c

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

разные способы ссылки на элемент в массиве! (Не совсем странно)

Немного истории сейчас. Среди других языков BCPL оказал довольно значительное влияние на раннее развитие C. Если вы объявили массив в BCPL с чем-то вроде:

let V = vec 10

это фактически выделило 11 слов памяти, а не 10. Как правило, V было первым и содержало адрес непосредственно следующего слова. Таким образом, в отличие от C, имя V пошло в это место и взяло адрес нулевого элемента массива. Поэтому косвенность массива в BCPL, выраженная как

let J = V!5

действительно нужно было сделать J = !(V + 5)(используя синтаксис BCPL), поскольку было необходимо выбрать V, чтобы получить базовый адрес массива. Таким образом V!5и 5!Vбыли синонимами. В качестве эпизодического наблюдения, WAFL (функциональный язык Warwick) был написан на BCPL, и, насколько я помню, имел тенденцию использовать последний синтаксис, а не первый для доступа к узлам, используемым в качестве хранилища данных. Конечно, это где-то между 35 и 40 годами назад, так что моя память немного ржавая. :)

Инновация избавления от лишнего слова хранения и того, чтобы компилятор вставлял базовый адрес массива, когда он был назван, появилась позже. Согласно историческому докладу C, это произошло примерно в то время, когда структуры были добавлены в C.

Обратите внимание, что !в BCPL был как унарный префиксный оператор, так и бинарный инфиксный оператор, в обоих случаях выполнял косвенное обращение. просто двоичная форма включала добавление двух операндов перед выполнением косвенного обращения. Учитывая словоориентированную природу BCPL (и B), это действительно имело большой смысл. Ограничение «указатель и целое число» было сделано необходимым в C, когда он получил типы данных, и sizeofстал чем-то особенным.

Ну, это особенность, которая возможна только из-за языковой поддержки.

Компилятор интерпретирует a[i]как *(a+i)и выражение5[a] вычисляет до *(5+a). Поскольку сложение коммутативно, оказывается, что оба равны. Следовательно, выражение оценивается как true.

В С

 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

Указатель является «переменной»

имя массива является "мнемоническим" или "синонимом"

p++; действует, но a++ недействителен

a[2] равен 2 [а], потому что внутренняя операция на обоих это

«Арифметика указателя» внутренне рассчитывается как

*(a+3) равно *(3+a)

типы указателей

1) указатель на данные

int *ptr;

2) постоянный указатель на данные

int const *ptr;

3) постоянный указатель на постоянные данные

int const *const ptr;

и массивы имеют тип (2) из ​​нашего списка.
Когда вы определяете массив одновременно, один адрес инициализируется в этом указателе.
Мы знаем, что мы не можем изменить или изменить значение const в нашей программе, потому что он выдает ОШИБКУ. при компиляции время

Основное различие я нашел ...

Мы можем повторно инициализировать указатель по адресу, но не в том же случае с массивом.

======
и вернемся к вашему вопросу ...
a[5]это ничего, но *(a + 5)
вы можете легко понять это,
a указав адрес (люди называют его базовым адресом), как указатель типа (2) в нашем списке
[]- этот оператор может быть заменяется указателем* .

так наконец ...

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