Хуже тролля может быть только тролль-зануда

Вопрос по теме: в чём разница между UB и unspecified?

Вопрос по теме: в чём разница между UB и unspecified?

Эх, korvin, korvin... Услышали звон, да не знаете... Суть же разговора не про эту запись (сложение чисел), а про запись f(++i,++i).

С учетом того, что выше ты написал что в математике эта запись представляется как +(3, 2)
Если я ее представлю как +(2 3) - это будет другое выражение? Или все тоже?

На чём это "на этом" основана "по сути вся математика"??? :blink: :blink: :blink: :blink: :blink: :blink:

Это следствие определений! Когда вы видите выражение "3+4+5", то можете, конечно, по-бабски эмоционально навычислять оное аки "(3+5)+4", но наука так не работает. Она сначала даёт железобетонное определение адекватным записям, определение того, что они означают (порядок и алгоритм расчёта), доказательства эквивалентности других способов подсчёта, и только потом уже люди решают как они поступят при подсчёте.

И тут нет никаких намеков на то, что я могу сделать так или эдак. Это факт вытекающий из самой теории чисел. На этом основана по сути вся математика.

В Rust его выпилили и правильно сделали.

А именно: уравнение не вычисляется, а решается. И решение - суть алгоритм, дающий что-то. Так что тут (в каком-то смысле) вообще иное, нежели вычислить "i=2, f(++i,++i)".

Было https://kristerw.blogspot.com/2017/09/why-u...call-never.html ?

Т.е. с твоей точки зрения, если результат гарантировано не отличается, то процесс всё равно неправильный? А почему, объяснишь? Ну, и эта... ты ж понимаешь, что что-то типа "потому что" за ответ считаться не будет.

Ну так Rust же не C++. А C++ наследует всё лучшее Cшное, а C – ассемблерное.

2. Запись вида "a+b+c" тоже никуда не лезет (даже в п.1), поэтому и ей даётся определение понимания. А именно как "(a+b)+c". При этом тут же выводится, что ввиду всяких коммутативностей да ассоциативностей позволительно считать и как "a+(b+c)", но это лишь намёк, что результат получится одинаковым.

2. Запись вида "a+b+c" тоже никуда не лезет (даже в п.1), поэтому и ей даётся определение понимания. А именно как "(a+b)+c". При этом тут же выводится, что ввиду всяких коммутативностей да ассоциативностей позволительно считать и как "a+(b+c)", но это лишь намёк, что результат получится одинаковым.

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

Язык (Си) был придуман англо-саксами, посему под такую дудку и пляшем.

Потому что так уcтроены законы математики/логики.

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

Расскажи пожайлуйста, почему в выражении:
X = 3 + 5 + 6 +7

Я не могу паралельно вычислить сумму 3 + 5 и 6 + 7, а потом сложить это все воедино?

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

С чего это он правильный? Потому что тебе так кажется?

Нашёлся, - я ж показал правильный ход построения вызова функции.

В смысле выход нашелся? Не нашелся ведь.

Ага! Т.е. выход нашёлся, но теперь начались наезды на какие-то другие последствия?

int X = 2;
//! Тут мой код:
// 1.Создаём область памяти в две ячейки, к коим никто не может обратиться (дабы не ломали, ...);
// 2.Пишем в каждую ячейку: ++X в первую, ++X во вторую (получили пару (3;4);
// 3.Кормим функции Sum значения из ячеек. Бинго.
Sum(еда1, еда2);

Напиши код на месте коментария, чтоб внутри функции один аргумент был равен 3, а второй 4.

Потому что первым идёт 3, а потом (дойдя до второго) оно становится 4. Всё логично. :yes:

Где логично то? По твоему после передачи первого аргумента в функцию - должно выполниться тело функции?

Ты передаешь одну переменную, не две.

Потому что первым идёт 3, а потом (дойдя до второго) оно становится 4. Всё логично. :yes:

Ты ждешь 3,4 - а почему не 4,4?

А) Годьте! Если только на этапе оптимизации, то это проблема недоделанного оптимизатора. Пусть осторожней работает! Если же не только, то давайте смотреть этот обыденный случай.

Бред. Жесть. Идиотизм...

Я не шибко улавливаю фразу "точка следования"

Порядок вычисления операндов любого C++ оператора, включая порядок вычисления аргументов функции в выражении вызова функции, и порядок вычисления вложенных выражений внутри любого выражения, не определён

Я не шибко улавливаю фразу "точка следования" (только путём общелогических умозаключений)

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

а деле имеет 4, 4 - что более логично.

Вот второе - не должно быть. Ибо префиксный оператор должен отработать до входа в функцию.

Всё абсолютно чётко. Нет никаких параллельных вычислений!! Как записано, так пусть и считает! :angry:

Если i вначале было равно 2, то первый должен пойти параметр 3, второй - 4, а потом вызов.