В чем разница между a+i и &a[i] для арифметики указателей в C++?

В стандарте С++, раздел [expr.sub]/1, вы можете прочитать:

Выражение E1[E2] идентично (по определению) выражению *((E1)+(E2)).

Это означает, что &a[i] точно такое же, как &*(a+i). Таким образом, вы должны сначала разыменовать * указатель, а затем получить адрес &. В случае, если указатель недействителен (т.е. nullptr, но также вне диапазона), это UB.

a+i основан на арифметике указателей. На первый взгляд это выглядит менее опасным, так как нет разыменования, которое точно было бы UB. Однако это также может быть UB (см. [expr.add]/4:

Когда выражение, имеющее целочисленный тип, добавляется к указателю или вычитается из него, результат имеет тип операнда указателя. Если выражение P указывает на элемент x[i] объекта массива x с n элементами, выражения P + J и J + P (где J имеет значение j) указывают на (возможно, гипотетический) элемент x[i + j], если 0 ≤ i + j ≤ n; в противном случае поведение не определено. Точно так же выражение P - J указывает на (возможно, гипотетический) элемент x[i - j], если 0 ≤ i - j ≤ n; в противном случае поведение не определено.

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

TL; DR: a+i и &a[i] оба правильно сформированы и создают нулевой указатель, когда a является нулевым указателем, а i равен 0, в соответствии (намерение) стандарта, и все компиляторы согласны.

a+i, очевидно, правильно сформирован согласно [expr.add]/4 из последний проект стандарта:

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

• Если P оценивается как значение нулевого указателя, а J оценивается как 0, результатом является значение нулевого указателя.
• [...]

&a[i] сложно. Согласно [expr.sub]/1, a[i] эквивалентно *(a+i), таким образом, &a[i] эквивалентно &*(a+i). Теперь в стандарте не совсем ясно, правильно ли сформировано &*(a+i), когда a+i является нулевым указателем. Но как @n.m. указывает в комментарий, намерение, записанное в cwg 232 должен разрешить этот случай.

Поскольку базовый язык UB должен быть пойман в константном выражении ([expr.const] /(4.6)), мы можем проверить, считают ли компиляторы эти два выражения UB.

Вот демо, если компиляторы думают, что константное выражение в static_assert является UB, или если они думают, что результат не true, то они должны выдать диагностику (ошибку или предупреждение) в соответствии со стандартом:

^{(обратите внимание, что здесь используются однопараметрические static_assert и constexpr lambda, которые являются функциями C++17, и лямбда-аргумент по умолчанию, который также довольно новый)}

static_assert(nullptr == [](char* a=nullptr, int i=0) {
    return a+i;
}());

static_assert(nullptr == [](char* a=nullptr, int i=0) {
    return &a[i];
}());

Судя по https://godbolt.org/z/hhsV4I, в этом случае все компиляторы ведут себя одинаково. , вообще не производя диагностики (что меня немного удивляет).

Однако это отличается от случая offset. Реализация, опубликованная в этого вопроса, явно создает ссылка (что необходимо для обхода определяемого пользователем operator&) и, таким образом, подлежит требованиям к ссылкам.