Як Джоел зазначає у підкасті № 34 Stack Overflow , у програмі мови програмування 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 (комутативність індексації масивів чітко згадується у Посиланні користувачів 1972 року на B ), яка отримала його від BCPL (керівництво від 1967 р.), Яке , можливо, отримало його навіть від більш ранні мови (CPL? Algol?).

Отже, ідея про те, що індексація масиву визначена в термінах додавання, і що додавання, навіть вказівник і ціле число, є комутативним, йде багато десятиліть на мови предків С.

Ці мови були набагато менш сильно набрані, ніж сучасна мова С. Зокрема, різницю між вказівниками та цілими числами часто ігнорували. (Програмісти раннього С іноді використовували вказівники як цілі числа без підпису, перш ніж unsignedключове слово було додано до мови.) Отже, ідея зробити додавання некомутативним, оскільки операнди різного типу, ймовірно, не виникли б у дизайнерів цих мов. Якщо користувач хотів додати дві "речі", будь то ці "цілі", цілі числа, покажчики чи щось інше, мова не могла запобігти.

І з роками будь-яка зміна цього правила порушила б існуючий код (хоча стандарт ANSI C 1989 р. Міг бути гарною можливістю).

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

Отже, ми маємо arr[3]і маємо на 3[arr]увазі саме те саме, хоча остання форма ніколи не повинна з’являтися поза МОККЦ .

І звичайно

 ("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- за адресою, де зберігається покажчик, а значення вказівника в цьому місці пам'яті є початком масиву.

Для покажчиків на С ми маємо

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

а також

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

Отже, це правда a[5] == 5[a].

Не відповідь, а просто трохи їжі для роздумів. Якщо у класу перевантажений оператор індексу / підписки, вираз 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&);
};

Це дуже вдале пояснення у навчальному посібнику з покажчиків та масивів на C від Теда Дженсена.

Тед Дженсен пояснив це так:

Насправді це правда, тобто там, де хто пише, a[i]його можна замінити *(a + i) без проблем. Фактично компілятор створить один і той же код в будь-якому випадку. Таким чином, ми бачимо, що арифметика вказівника - це те саме, що і індексація масиву. Будь-який синтаксис дає однаковий результат.

Це НЕ говорить про те, що вказівники та масиви - це одне і те ж, це не так. Ми лише говоримо, що для ідентифікації заданого елемента масиву у нас є вибір двох синтаксисів, один з використанням індексації масиву, а другий з використанням арифметики вказівника, які дають однакові результати.

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

char a[20];

написання

a[3] = 'x';

те саме, що писати

3[a] = 'x';

Я знаю, що на це питання відповіли, але я не втримався поділитися цим поясненням.

Я пам’ятаю Принципи дизайну компілятора, припустимо a, це intмасив і розмір int- 2 байти, а базова адреса a- 1000.

Як 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 мала досить великий вплив на ранній розвиток С. Якщо ви оголосили масив у 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), це насправді мало сенс. Обмеження "покажчик і ціле число" стало необхідним у С, коли він набирав типи даних, і 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], тому що внутрішня операція на обох це

"Арифметика вказівника" внутрішньо розраховується як

*(a+3) дорівнює *(3+a)

типи вказівників

1) вказівник на дані

int *ptr;

2) const вказівник на дані

int const *ptr;

3) покажчик const на дані const

int const *const ptr;

і масиви є типом (2) з нашого списку.
Коли ви визначаєте масив одночасно, одна адреса ініціалізується в цьому покажчику.
Як ми знаємо, що ми не можемо змінити або змінити значення const у нашій програмі, тому що він кидає помилку при компіляції час

Основна відмінність я знайшов ...

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

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

так нарешті ...

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