C++ арифметика указателей: является ли код эквивалентным?

бросайте этого тролля

Да вот тоже всё больше и больше склоняюсь к тому, что это тролинг. Хотя полной уверенности пока нет. Вдруг он действительно что-то не понимает и хочет разобраться?

тот кто хочет разобраться, тот берет и разбирается
молодые люди окончившие школу, или тем более ВУЗ должны способны к самостоятельному анализу и разбору
если они на это не способны, значит им нужно закончить школу, либо повторно пойти учится, форумы это не то место которые должны заменять эти два жизненных института(школу, ВУЗ)

Ты модифицировал элемент массива, а не объект

Т.е, по-твоему, после a[0] = 0; массив не изменился???

который является константным указателем на 0-й элемент.

При чём тут какие-то константные указатели????

в стандарте есть то, о чём ты говорил, что его нет.

И по прежнему говорю, что нет. Нет обоснования всей цепочки преобразований.

Т. е. то, что я допустил возможность того, что поищу за тебя и, если что, отпишусь, но не обещаю — это хамство?!

Хамство — это «А дальше читай про приведение типов». Типа ты уверен и проверил, что дальше всё доказывается элементарно, после прочтения про приведение типов. Хотя на самом деле ты просто не в курсе, как обосновывать дальше.

При чём тут какие-то константные указатели????

При том.

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

При том.

От вопроса про то, изменился ли массив, ты решил уйти?

По-моему, ты действительно троль

А по-моему — ты.

и дальнейший разговор бесполезен

С тобой так точно.

на любой разумный аргумент и цитату из стандарта ты будешь отвечать бредом

«При том» — это разумный аргумент и/или цитата из стандарта?

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

От вопроса про то, изменился ли массив, ты решил уйти?

Сейчас я тебе покажу на пальцах, на чём ты прокололся.

Сначала ты утверждал, что

компиляторы не компилируют код с присваиванием массивов.

А потом сказал:

Т.е, по-твоему, после a[0] = 0; массив не изменился???

Т. е. ты утверждаешь, что присвоил массиву новое значение, если понимать под массивом не ссылку на 0-й элемент, а весь контейнер. Но тогда первое твоё утверждение (в этом понимании) было ложью. Т. е. ты говоришь о совершенно разных вещах (в одном случае о ссылке, а в другом — о контейнере) и, пользуясь тем, что эти разные вещи называются одним словом, находишь какие-то несуществующие противоречия.

Я понимаю, что ты найдёшь множество демагогических «контр-аргументов». Но на таком уровне мне общаться просто неинтересно. Поэтому, если ты действительно чего-то не понимаешь, мой тебе совет — взять хорошую книжку по си (си++ в данном случае даже не нужен, там много дополнительных вещей, которые тебя только запутают, а соответствие массивов указателям верно и там, и там, и это азы, без которых ни си, ни си++ не понять). А на форуме без понимания этих азов тебе ничего объяснить не получится — формат не тот.

Ну а если ты всё это знаешь и просто тебе охота потролить от скуки, то ищи других тролей.

тратит свое время что бы понять

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

Сейчас я тебе покажу на пальцах, на чём ты прокололся.

Извини, но у тебя не вышло.

Сначала ты утверждал, что

компиляторы не компилируют код с присваиванием массивов.

Да. И ведь это действительно так! Например https://ideone.com/BdUzkI

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

А тут либо сознательная ложь, либо тебе померещилось. Потому что я такого не утверждаю.

если понимать под массивом не ссылку на 0-й элемент, а весь контейнер.

Понимать можно как угодно. Так или иначе, я не говорил, что я присвоил массиву. И не присваивал массиву.

ты говоришь о совершенно разных вещах (в одном случае о ссылке, а в другом — о контейнере)

Откуда ты вообще взял что я говорю о ссылках или контейнерах? Это ты говоришь о каких-то константных указателях, но так и не объяснил толком, при чём тут они.

Я понимаю, что ты найдёшь множество демагогических «контр-аргументов».

Пока что тут ты демагогически приписываешь мне чушь, потом её героически опровергаешь и это, видимо, должно выглядеть так, что ты предъявил МНЕ контр-аргументы.

Из списка приёмов демагога:

Приписывание оппоненту слов, которые он не говорил.

Есть такое? Есть:

ты утверждаешь, что присвоил массиву

Я такого не утверждал.

Ещё приём демагога:

Увертка от вопроса. На вопрос не отвечают, потому, что это крайне не выгодно. При этом либо задают встречный вопрос, либо переходят на обвинение в чем-то оппонента, либо переходят на другую тему. Вобщем, все, что угодно, только не ответ на вопрос.

На вопрос «изменился ли массив» ясного ответа не последовало. На вопрос «при чём тут константные указатели» был получен ответ «при том». Потом пошли обвинения в троллинге.

Ну а если ты всё это знаешь

Да, я всё это знаю. В отличие от тебя.

охота потролить

Ещё раз повторяю, я не вбрасывал тут заведомо ложных утверждений с провокационными целями, т.е. я не троллю.

А то, что я пытаюсь получить внятные аргументы от оппонентов — это не троллинг.

Например https://ideone.com/BdUzkI

  int a[10], b[10];
  a = b;

В последний раз для танкистов:

константным указателем на 0-й элемент

соответствие массивов указателям

совет — взять хорошую книжку по си

В последний раз для танкистов:

Да, в последний раз, для тебя:

константным указателем на 0-й элемент

При чём тут константный указатель на нулевой элемент?

соответствие массивов указателям

У тебя есть внятные аргументы, подкреплённые пунктами стандарта, или «это азы» — всё, что у тебя есть?

совет — взять хорошую книжку по си

Это опять «ответ» на уровне

А дальше читай про приведение типов.

— это типичное хамство.

Серьезно? «Я может тебе помогу, незнакомый мне человек, но не точно, ибо времени нет у самогу» - это хамство? Или у тебя кроме с++ и с русским проблемы?

Т.е, по-твоему, после a[0] = 0; массив не изменился???

Ты путаешь определение массива из теории алгоритмики и из языка.

  char* ch = new char[100];

  std::array<char, 100> ch;

И то и другое является массивом по логике, но не по языку.

От вопроса про то, изменился ли массив, ты решил уйти?

Изменились данные. Массив остался на месте. В стандарте под массивом понимается не последовательный кусок байт из памяти.

Серьезно?

Да.

«Я может тебе помогу, незнакомый мне человек, но не точно, ибо времени нет у самогу» - это хамство?

Нет.

Или у тебя кроме с++ и с русским проблемы?

Не проецируй. Из моего сообщения понятно, что хамством я назвал не то, что мне не обещали помочь за неименеием времени, а посылание меня читать про что-то, при том, что посылающий не знает, поможет ли это.

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

Ты путаешь определение массива из теории алгоритмики и из языка.

С чего ты взял?

И то и другое является массивом по логике, но не по языку.

Под массивом я везде подразумеваю «массив по языку», т.е. то, что в стандарте называют «array object» или «object of array type».

Да.

У тебя шизофазия.

Нет.

Но тебе дословно так и ответили, лол.

Изменились данные. Массив остался на месте.

Ну и что, что он остался на месте?

struct S { int a; } s {0};
s.a = 1

Изменился ли объект s?

int a = 0;
a = 1;

Изменился ли объект a?

Если объект a «остался на месте», то он не изменился после a = 1;, я правильно понял? Или такое определение изменения — остался или не остался на месте — относится только к массивам?

В стандарте под массивом понимается не последовательный кусок байт из памяти.

Ого. А это прогресс :)

Такими темпами, может быть, к 20-й странице появится правильный ответ на вопрос из ОП-поста =)

Такими темпами, может быть, к 20-й странице появится правильный ответ на вопрос из ОП-поста =)

То есть ты знаешь ответ, но не говоришь? То есть ты считаешь, что есть некое заблуждение, знаешь в чем оно, но издеваешься над людьми? Тогда ты тролль.

Или ты не понимаешь вещей которые понятны вчем и не хочешь сам искать ответы? Тогда ты дурак.

Выбирай из двух зол=)

Вообще, во втором коде определённо присутствует UB.

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

Но на данный момент я скажу, что во втором коде определённо UB, а первый вроде ничего так.

Но на данный момент я скажу, что во втором коде определённо UB, а первый вроде ничего так.

Еще говоришь что не тролль? У тебя друзья то есть?

В общем, переписал первый код так, что в нём не должно остаться UB (я надеюсь).

Второму коду замена каста и launder не помогут, так что даже не стал его менять.

Не вижу причин, почему было бы не так.

http://eel.is/c++draft/expr.add#4

When an expression that has integral type is added to or subtracted from a pointer, the result has the type of the pointer operand. If the expression P points to element x of an array object x with n elements, the expressions P + J and J + P (where J has the value j) point to the (possibly-hypothetical) element x[i+j] if 0≤i+j≤n; otherwise, the behavior is undefined. Likewise, the expression P - J points to the (possibly-hypothetical) element x[i−j] if 0≤i−j≤n; otherwise, the behavior is undefined.

А теперь что ты видишь?

Ничего нового? Учитывая (хотя приписка «by definition» не понятно к чему)

http://eel.is/c draft/expr.add#4

[...] The expression E1[E2] is identical (by definition) to *((E1)+(E2)) [...]

Конечно паддинг может где-то быть, но для float не должно. А так если в одном случае будет UB, то и во втором тоже.

Ничего нового?

Что, совсем не смутило, что для арифметики указателей требуется указатель на элемент массива, а во втором случае (float*)stor — это не указатель на элемент массива?

А так если в одном случае будет UB, то и во втором тоже.

В первом случае точно нет UB из-за арифметики.

Что, совсем не смутило, что для арифметики указателей требуется указатель на элемент массива?

Если так интерпретировать, то контейнеры получаются с UB, разве нет? Они же выделяют память как байты, потом кастуют указатель и делают placement new поэлементно, а потом индексирование и арифметика с указателями применяются.

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

Если так интерпретировать, то контейнеры получаются с UB, разве нет?

Смотря как использовать, но вообще да, самому вектор-лайк контейнер на C++ без UB не написать. Единственное что можно сказать: раз стандарт говорит, что вектор работает, значит он работает, даже если его нельзя реализовать на C++.

В стандартной библиотеке вектор — не единственная вещь, которую нельзя написать на C++. Тот же offsetof сам на C++ без UB не сделаешь, но offsetof-ом из стандартной библиотеки пользоваться можно.

Они же выделяют память как байты, потом кастуют указатель и делают placement new поэлементно, а потом индексирование и арифметика с указателями применяются.

В operator[] у вектора можно нужно делать так, как в первом коде, тогда UB нет. А достать указатель из вектора (как адрес первого элемента или вызовом data()) и использовать его как указатель на первый элемент массива с точки зрения Core C++ — UB. Но если мы скажем, что раз стандарт разрешает так делать — то не UB.

Так как не написано, что массив должен быть правильного типа

expression P points to element x of an array object x with n elements

Должно именно указывать на существующий элемент (или на 1 гипотетический элемент за концом) существующего массива.

Меня это смущяет, так как это очень сильно ограничивает возможности расширения C++ классами. И вот это меня настораживает:

http://eel.is/c draft/expr.add#4

If the expression P points to element x of an array object x with n elements, <86>

Этого «if» не было бы, если бы абсолютно все указатели на объекты считались указателями на массивы. Сноска:

<86> An object that is not an array element is considered to belong to a single-element array for this purpose; see [expr.unary.op].

А там:

http://eel.is/c draft/expr.unary.op#3

For purposes of pointer arithmetic ([expr.add]) and comparison ([expr.rel], [expr.eq]), an object that is not an array element whose address is taken in this way is considered to belong to an array with one element of type T.

Может «address taken in another way» может существовать и на него не накладываются такие ограничения? Иначе мне тот «if» не понятен.

очень сильно ограничивает возможности расширения C++ классами

В смысле, не позволяет самостоятельно реализовывать вектор-лайк контейнеры? Есть такое, над исправлением подобного работают: http://wg21.link/p0593r2

Этого «if» не было бы, если бы абсолютно все указатели на объекты считались указателями на массивы.

Не совсем понимаю, что ты имеешь в виду.

Да, единичный объект с точки зрения адресной арифметики можно рассматривать как одноэлементный массив. Но во втором коде попытка использовать как трёхэлементный.

А if идёт в паре с «otherwise, the behavior is undefined».

Может «address taken in another way» может существовать и на него не накладываются такие ограничения?

Вряд ли такое есть в C++. Объект (в данном случае — массив из трёх float) либо есть, либо его нет, вне зависимости от того, как ты получил на него указатель. Неявно объекты в C++ не появляются. Пока что.

Тогда возражений нет, спасибо. Просто если это UB, то объёмы UB в существующем коде на C (там аналогичное скорее всего) и C++ в моём сознании только что возросло на несколько порядков.

Все (в т.ч. я) всегда интерпретировали

http://eel.is/c++draft/basic.life#1

The lifetime of an object of type T begins when
— storage with the proper alignment and size for type T is obtained, and
— if the object has non-vacuous initialization, its initialization is complete

как то, что в C++ можно создавать объекты достаточно тривиальных типов с помощью malloc.

Но некоторое время назад кому-то в комитете ударила моча в голову и решили, что это не верно, а объекты создаются только так:

An object is created by a definition, by a new-expression, when implicitly changing the active member of a union, or when a temporary object is created.

а те пункты про сторадж не являются дополнением этого правила.

(Честно говоря, с решением Партии я до сих пор до конца не согласен, ну да ладно.)

Ээээ, т.е. они объявили это

int *ints = static_cast<int*>(malloc(10*sizeof(int)));
ints[0] = 10;
std::cout << ints[0] << '\n';

Да. Весь код с malloc нелегален.

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0593r2.html#idiomatic-c-code-as-c

Consider the following natural C program:

struct X { int a, b; };
X *make_x() {
  X *p = (X*)malloc(sizeof(struct X));
  p->a = 1;
  p->b = 2;
  return p;
}

When compiled with a C++ compiler, this code has undefined behavior, because p->a attempts to write to an int subobject of an X object, and this program never created either an X object nor an int subobject.

В С++98:

An object is created by a definition (3.1), by a new-expression (5.3.4) or by the implementation (12.2) when needed.

Если нет зависимости от других определений, то судя по всему оно так всегда было.

оно так всегда было.

UB с malloc?

Да.

Да, комитет решил, что типичный C-код, оказывается, всегда был сплошным UB с т.з. C++.

Неявно объекты в C++ не появляются.

Т.е. временные, конечно, появляются неявно.

Я имел в виду, что из-за обращения к куску памяти каким-то образом они там не образуются для легализации данного способа обращения.

Хотите сказать что надо так что ли?

new (&ints[0]) int{10};

Судя по всему, строго в терминах стандарта как-то так и надо (как бы ещё не пришлось использовать указатель, который вернул new, либо std::launder).

Мда, std::launder я упустил. Еще, конечно, не забыть ints[0].~int(), или как оно теперь будет.

Выглядит как-то абсурдно. Зачем всё это? Готовят что-то принципиально новое, типа лайфтаймов? Или уже сейчас есть проблемы с маллоками etc?

Еще, конечно, не забыть ints[0].~int(), или как оно теперь будет.

Не обязательно, можно просто освободить память.

Выглядит как-то абсурдно. Зачем всё это?

Чтобы усидеть на двух стульях: с одной стороны, разрешить относительно низкоуровневые вещи, типа выделения памяти malloc-ом или «создание» массива просто созданием подряд элементов в непрерывном куске памяти, а с другой не сваливаться полностью на уровень представления, а формально рассуждать о поведении C++-программ в терминах объектов, а не байтов.

Или уже сейчас есть проблемы с маллоками etc?

Нет, но надо формально объяснить, почему их нет.
Стандарт стандартизирует стандартные практики.