Здравствуйте, MTD, Вы писали:
MTD>Изменение одной переменной более одного раза не пересекая точку следования (sequence points) — UB.
Следует заметитть что, начиная с 11-го стандарта, точки следования убрали, как таковые, и ввели вместо них понятия "sequenced before" и "unsequenced". Но на результат это не повлияло, в данном случае, действительно имеем UB (поскольку вычисление операндов оператора сложения "unsequenced"):
ISO/IEC/14882-2011
1.9/15
Except where noted, evaluations of operands of individual operators and of subexpressions of individual expressions are unsequenced. [ Note: In an expression that is evaluated more than once during the execution of a program, unsequenced and indeterminately sequenced evaluations of its subexpressions need not be performed consistently in different evaluations. —end note ] The value computations of the operands of an operator are sequenced before the value computation of the result of the operator. If a side effect on a scalar object is unsequenced relative to either anotherside effect on the same scalar object or a value computation using the value of the same scalar object, the behavior is undefined. [ Example:
void f(int, int);
void g(int i, int* v) {
i = v[i++]; // the behavior is undefined
i = 7, i++, i++; // i becomes 9
i = i++ + 1; // the behavior is undefined
i = i + 1; // the value of i is incremented
f(i = -1, i = -1); // the behavior is undefined
}
--
Не можешь достичь желаемого — пожелай достигнутого.
Здравствуйте, Vain, Вы писали:
N>>Зависит от компилятора и того что тебе нужно. V>Нормальный компилятор не будет дополнительно "подсирать" логику даже несмотря на УБ.
Здравствуйте, Mr.Delphist, Вы писали:
MD>Оптимизатор выкидывает кусок кода, посчитав какой-то ифчик заранее предвычисляемым. Этот ифчик уберегал от вызова "format c: /y" (или что там по параметрам у него — не помню). В результате, дебажная сборка работает как надо, релизная — форматит диск независимо от телодвижений поциЭнта.
Глупости. В реальности будет как мининум код подтверждением намерений выстрелить себе в ногу, наподобии "повторите ввод пароля", да ещё и с задержкой.
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Здравствуйте, Мёртвый Даун, Вы писали:
МД>Пора бы уже отходить от строгих канонов когда компилятор рубит пальцы. Наоборот, он должен быть моим другом и помощником. Предвидеть мои действия, исправлять их изо всех сил, даже если с утра я выпил коньяку.
Всё верно! Почувствовал запах алкоголя — заблокировал консоль.
Определил такой код, как ТС написал — ампутировал руки программисту, чтобы больше не писал такого.
Здравствуйте, alzt, Вы писали:
N>>Люблю порядок. Меня учили что ЮБ имеет право тебе диск отформатировать.
A>Почти все программы содержат UB и разработчики компиляторов об этом знают.
Ну баги принципиально неискоренимы, при разработке в стиле предлагаемом императивными языками.
Здравствуйте, K13, Вы писали:
K13>Здравствуйте, c-smile, Вы писали:
K13>
K13>printf("%d", ++a + (++a + ++a));
K13>
K13>и получаем 15
Дык тоже самое
берём первое слагаемое увеличиваем a=3
берём второе скобки
берём первое в скобках увеличиваем a=4
берём второе увеличиваем a=5
складываем a+a = 5+5 = 10
результат складываем с a
a+10=5+10=15
По выражению ++a + ++a + ++a компилятор, построит такое дерево разбора:
+
/ \
/ \
++a(1) ++a(2)
\
\
+
\
\
++a(3)
и сгенерирует примерно такой код (x86):
inc a ; a = 3 (1) в скобочках - порядковый номер инкремента в примере
inc a ; a = 4 (2)
mov eax, a ; a = 4, eax = 4
add eax, a ; a = 4, eax = 8
inc a ; a = 5 (3), eax = 8
add eax, a ; a = 5, eax = 13
Компилятор честно выполнил инкремент до сложения и складывал с результатами инкремента . Результат зависит от платформы, компилятора и от того, какие параметры оптимизации кода были указаны при компиляции. Не нужно писать в коде выражения ++a + ++a + ++a, если нет желания устраивать пляски с бубном для поиска непонятных ошибок.
Здравствуйте, Vain, Вы писали:
AD>>c-smile и UB: первая встреча. V>не смотря на УБ, оно сработало как и должно
Зависит от компилятора и того что тебе нужно.
Здравствуйте, Nikе, Вы писали:
AD>>>c-smile и UB: первая встреча. V>>не смотря на УБ, оно сработало как и должно N>Зависит от компилятора и того что тебе нужно.
Нормальный компилятор не будет дополнительно "подсирать" логику даже несмотря на УБ.
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Здравствуйте, Nikе, Вы писали:
N>>>Зависит от компилятора и того что тебе нужно. V>>Нормальный компилятор не будет дополнительно "подсирать" логику даже несмотря на УБ. N>А надо бы.
Зачем? Любишь извращения?
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Здравствуйте, Vain, Вы писали:
N>>>>Зависит от компилятора и того что тебе нужно. V>>>Нормальный компилятор не будет дополнительно "подсирать" логику даже несмотря на УБ. N>>А надо бы. V>Зачем? Любишь извращения?
Люблю порядок. Меня учили что ЮБ имеет право тебе диск отформатировать.
Здравствуйте, Nikе, Вы писали:
N>Люблю порядок. Меня учили что ЮБ имеет право тебе диск отформатировать.
Плохо учили, УБ в одном месте не в праве порождать УБ в другом.
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Здравствуйте, Vain, Вы писали:
N>>Люблю порядок. Меня учили что ЮБ имеет право тебе диск отформатировать. V>Плохо учили, УБ в одном месте не в праве порождать УБ в другом.
Здравствуйте, Nikе, Вы писали:
N>>>Люблю порядок. Меня учили что ЮБ имеет право тебе диск отформатировать. V>>Плохо учили, УБ в одном месте не в праве порождать УБ в другом. N>Не уловил логики.
форматирование диска от неправильной последовательности сложения в каком-то кривом приложении это независимое УБ.
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Здравствуйте, Vain, Вы писали:
V>Здравствуйте, Nikе, Вы писали:
N>>>>Люблю порядок. Меня учили что ЮБ имеет право тебе диск отформатировать. V>>>Плохо учили, УБ в одном месте не в праве порождать УБ в другом. N>>Не уловил логики. V>форматирование диска от неправильной последовательности сложения в каком-то кривом приложении это независимое УБ.
Оптимизатор выкидывает кусок кода, посчитав какой-то ифчик заранее предвычисляемым. Этот ифчик уберегал от вызова "format c: /y" (или что там по параметрам у него — не помню). В результате, дебажная сборка работает как надо, релизная — форматит диск независимо от телодвижений поциЭнта.
Здравствуйте, Masterspline, Вы писали:
N>>>Люблю порядок. Меня учили что ЮБ имеет право тебе диск отформатировать. V>>Плохо учили, УБ в одном месте не в праве порождать УБ в другом. M>UB в любом месте — это полный UB, глобальный и бесповоротный. Не надо недооценивать UB.
Нет конечно. Компилятор дложен страховать в этом месте, иначе накой он нужен?
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Здравствуйте, Vain, Вы писали:
V>Нормальный компилятор не будет дополнительно "подсирать" логику даже несмотря на УБ.
Подсирать не будет. Но UB на то и UB, что результат не определён и может отличаться у разных компиляторов.
На данном примере gcc даёт результат 13, а MSVC 15.
Здравствуйте, Vain, Вы писали:
V> Компилятор дложен страховать в этом месте, иначе накой он нужен?
Это в голанге компилятор страхующий.
Компилятор С++ никому ничего не дложен, окромя следования стандарту. Он даже предупреждения выдавать не обязан (стандарт говорит, что "implementations are encouraged to issue a warning").
Пора бы уже отходить от строгих канонов когда компилятор рубит пальцы. Наоборот, он должен быть моим другом и помощником. Предвидеть мои действия, исправлять их изо всех сил, даже если с утра я выпил коньяку.
Только Путин, и никого кроме Путина! О Великий и Могучий Путин — царь на веки веков, навсегда!
Смотрю только Соловьева и Михеева, для меня это самые авторитетные эксперты.
КРЫМ НАШ! СКОРО И ВСЯ УКРАИНА БУДЕТ НАШЕЙ!
Здравствуйте, Nikе, Вы писали:
A>>Почти все программы содержат UB и разработчики компиляторов об этом знают.
N>Ну баги принципиально неискоренимы, при разработке в стиле предлагаемом императивными языками.
Да при любом стиле, люди ошибаются. К счастью разработчики компиляторов не наказывают за это специально. UB может привести к очень неприятным последствиям, даже хуже, чем форматирование диска, но никто специально вставлять какую-то гадость в этом случае не будет. И в большинстве случаев последствия будут довольно локальными.