Комментарии 40
Критика формулировок, замечания по содержанию и оформлению категорически приветствуются.
deleted
Да пожалуйста. Понятие «точка следования» удалено из С++ начиная со стандарта С++11. Суть языка не изменилась, но вот термина такого больше нет. Пруф: en.wikipedia.org/wiki/Sequence_point
Я извиняюсь, но вы статью вообще читали? Цитата из середины:
Или это тоже некорректное объяснение (сам не в курсе)?
Я слышал, что в C++0x нет никаких Точек Следования, это правда?
Да, это правда.
Понятие «точка следования» было заменено комитетом ISO C++ на уточненное и дополненное понятие Отношения Следования [ДО\ПОСЛЕ].
Или это тоже некорректное объяснение (сам не в курсе)?
Если быть точным, то было заменено на понятия отношений «sequenced before» / unsequenced (могут перекрываться).
Немного смущает название статьи Undefined Behaviour при рассмотрении лишь одного из его аспектов (ведь UB встречается не только в вычислении выражений с побочными эффектами).
Немного смущает название статьи Undefined Behaviour при рассмотрении лишь одного из его аспектов (ведь UB встречается не только в вычислении выражений с побочными эффектами).
В том-то и дело, что актуальную информацию убрали в середину статьи. Я тоже споткнулся на 4-м абзаце, но поборол желание написать комментарий и продолжил читать дальше.
Добавьте тэг «никто не читает статью полностью» :)
Не критика, но я бы не стал переводить выдержки из стандарта. По-моему, ухудшает понимание.
Из текста следует что выражение «f(i = -1, i = -1);» есть неопределённое поведение. Но ведь это не так. Опечатка в выражении, или смысловая ошибка? Или оно всё же считается формально неопределённым, хотя и имеет строго определённый результат?
Формально считается неопределенным (ISO C++ 1.9.15).
Это, ктсати, какая-то жесть. Можно рассуждать так: вычисление операндов функции любое. Если существуют два таких порядка вычисления, которые приводят к различным результатам, то это неопределённое поведение. Если не существует — то нет. А вот в этом примере такая логика не работает что ли?
Работает такая логика, что в данном коде совершается более одной модификации состояния i в ходе вычисления полного выражения. Компилятор не проводит анализа, позволяющего увидеть, что присваивается одно и то же значение.
Что значит «не проводит анализа»? Удаление общих подвыражений — стандартная оптимизация и все компиляторы её содержат.
Ну тут другая логика срабатывает первой:
1. У нас тут кусочек, который потенциально может вызвать неопределённое поведение.
2. Но у нас при всё притом программа на C/C++ (если кто-то компилирует с помощью компилятора что-то другое, то он ССЗБ).
2a. А мы знаем, что никакая программа на C/C++ в принципе никогда не может вызвать неопределённое поведение.
3. А это, в свою очередь, значит, что этот код никогда не исполняется.
4. Но так это же круто! Мы можем врубить на полную катушку, скажем удаление мёртвого кода и получить бааальшую экономию на этом.
Очень часто люди исходят из странной логики: «да, у меня тут неопределённое поведение, но, чёрт побери, что может случиться плохого?». А компилятор — он доверчив, он каждый такой кусок воспринимает как клятвенное обещание программиста. Типа: «мамой клянусь (ну или там — руками, ногами, зубами), что вот этот вот код исполняться не будет». Как вы этого собираетесь добиваться — это ваше дело, но если уж вы написали "
Ну тут другая логика срабатывает первой:
1. У нас тут кусочек, который потенциально может вызвать неопределённое поведение.
2. Но у нас при всё притом программа на C/C++ (если кто-то компилирует с помощью компилятора что-то другое, то он ССЗБ).
2a. А мы знаем, что никакая программа на C/C++ в принципе никогда не может вызвать неопределённое поведение.
3. А это, в свою очередь, значит, что этот код никогда не исполняется.
4. Но так это же круто! Мы можем врубить на полную катушку, скажем удаление мёртвого кода и получить бааальшую экономию на этом.
Очень часто люди исходят из странной логики: «да, у меня тут неопределённое поведение, но, чёрт побери, что может случиться плохого?». А компилятор — он доверчив, он каждый такой кусок воспринимает как клятвенное обещание программиста. Типа: «мамой клянусь (ну или там — руками, ногами, зубами), что вот этот вот код исполняться не будет». Как вы этого собираетесь добиваться — это ваше дело, но если уж вы написали "
if (this == NULL) { ... }", то тем самым пообещали компилятору, что то, что в фигурных скобках никогда исполнено не будет. Компилятор и саму проверку и весь этот код с превеликим удовольствием из программы удалит: она от этого только меньше и быстрее станет.Вы сейчас объяснили дизайнерские решения, скрывающиеся за самим понятием undefined behaviour. Это как в случае с многопоточностью, программист обязуется писать data-race free код, а язык в ответ гарантирует детерменированное поведение программы.
Я же объяснил, почему здесь возникает UB (потому что происходит более одной модификации состояния одной и той же переменной). Мне не стоило писать по поводу проведения анализа, я не хотел отрицать dead code, common subexpression и прочие оптимизации :-)
Я же объяснил, почему здесь возникает UB (потому что происходит более одной модификации состояния одной и той же переменной). Мне не стоило писать по поводу проведения анализа, я не хотел отрицать dead code, common subexpression и прочие оптимизации :-)
Очень много вотзефаков у начинающих программистов возникает по поводу i++ + i++ и f(i=1,i=1).
Казалось бы, всё доступно компилятору, можно было бы и определиться (прокачать UB до implementation-defined, хотя бы).
А вы подумайте вот о каком коде, например:
Казалось бы, всё доступно компилятору, можно было бы и определиться (прокачать UB до implementation-defined, хотя бы).
А вы подумайте вот о каком коде, например:
void f(int, int);
void foo( int& x, int& y)
{
int z = x++ + y++;
f(x=1, y=1);
}
Кстати говоря, просто не надо так писать. Подобный код это большие проблемы при автомержах, рефакторингах, и т.д, да и вообще читается так себе. Ведь достаточно просто написать красиво, что бы код был человекопонятным:
Производительность при этом не только не пострадает, но легко может и возрасти, ибо для компилятора такой код понятнее, поэтому z компилятор может получить совсем красивым и простым путём (здесь имеется ввиду уже ассемблер):
В общем мораль неопределённого поведения проста — не усложняйте никому жизнь (себе, коллегам, компилятору).
А то и ещё более упростить:
и вуаля, оказывается очевидным любому, что f у нас с константами работает (компилятор обычно сам догадывается о таком при оптимизациях, а вот человеку читать гораздо легче).
void f(int, int);
void foo( int& x, int& y)
{
int z = x+1 + y+1;
x = 1; y = 1;
f(x, y);
}
Производительность при этом не только не пострадает, но легко может и возрасти, ибо для компилятора такой код понятнее, поэтому z компилятор может получить совсем красивым и простым путём (здесь имеется ввиду уже ассемблер):
int z = 2;
z += x;
z += y;
В общем мораль неопределённого поведения проста — не усложняйте никому жизнь (себе, коллегам, компилятору).
А то и ещё более упростить:
void f(int, int);
void foo( int& x, int& y)
{
int z = x+1 + y+1;
x = 1; y = 1;
f(1, 1);
}
и вуаля, оказывается очевидным любому, что f у нас с константами работает (компилятор обычно сам догадывается о таком при оптимизациях, а вот человеку читать гораздо легче).
видимо, имелось в виду, что в обоих случаях значение i будет -1. Поправил.
Наверняка так и задумано, и строго определенного результата не имеет.
stackoverflow.com/a/21671069
stackoverflow.com/a/21671069
О, отличная ссылка, спасибо.
А вот эта ссылка даёт радикально лучшее понимание, чем стандарт (стандарт не даёт такого, потому что по ссылке детали реализации, но тем не менее очень помогающие в понимании). Я с такой точки зрения не смотрел даже. Спасибо.
добавлю, пожалуй, эти пару абзацев примечанием в статью после этого примера чуть позже
Это только кажется, что определенный. Компилятор может написать (псевдоассмеблер)
И упорядочить при вызове функции инстуркции так:
// i = -1;
xor i, i
sub i, 1
И упорядочить при вызове функции инстуркции так:
xor i, i
xor i, i
sub i, 1
sub i, 1
call f(i, i)
Правильно ли я понимаю, что выражение i * i++ приводит к неопределённому поведению по той причине, что side effect от инкремента начинает действовать сразу после входа в ветвь вычисления правого операнда, а не после вычисления всего выражения? И выражение при начальном i = 5 может дать результат как 25 (если компилятор решит сначала просчитать левую ветвь), так и 30 (если правую)?
Это логика, которой руководствовались разработчики стандарта, да. Но раз уж они включили подобное поведение в соответствующий список, то дальше это значит уже совсем другое.
Не пытайтесь «додумать» за компилятор логику обработки неопределённых поведений. Её нету. А есть только указание на то, что данный конкретный код никогда не будет выполняться с такими значениями, с которыми он мог бы вызвать неопределённое поведение. Сможет ли из этого знания компилятор извлечь какую-нибудь пользу и удалить, скажем,
— зависит от компилятора. Но не думайте что если сегодня, сейчас, ваш компилятор до этого не додумался, то и следующая, улучшенная версия тоже этого не сможет сделать. Очень может быть что сможет — и вам придётся долго и упорно сидеть в отладчике и офигевать от происходящего.
Не пытайтесь «додумать» за компилятор логику обработки неопределённых поведений. Её нету. А есть только указание на то, что данный конкретный код никогда не будет выполняться с такими значениями, с которыми он мог бы вызвать неопределённое поведение. Сможет ли из этого знания компилятор извлечь какую-нибудь пользу и удалить, скажем,
if (abs(x) < 0) { /* обработаем случай когда x == MIN_INT */ }— зависит от компилятора. Но не думайте что если сегодня, сейчас, ваш компилятор до этого не додумался, то и следующая, улучшенная версия тоже этого не сможет сделать. Очень может быть что сможет — и вам придётся долго и упорно сидеть в отладчике и офигевать от происходящего.
Спасибо, я как раз по этому собирал информацию (как профессионал, уточнял знакомому преподу лекцию).
Говоря о неопределённом поведении, стоит упомянуть о разновидностях плохого кода, ведущего к UB.
1. Неопределённость времени компиляции.
Например, берём любую сомнительную арифметику (например, (-1)>>1 или 1<<100) и используем как константы времени компиляции.
Нарушение ODR, опять же.
2. Низкоуровневые проблемы, связанные с нарушением алиасинга и гонками чтения-записи — всё тот же i++ + i++
3. Огромный класс проблем с неинициализированными и повреждёнными переменными (включая гонки конструкторов статических объектов, нулевые указатели, кривая адресная арифметика, стрельба по памяти)
4. Нарушение контрактов (например, std::map с компаратором, не удовлетворяющим аксиоматике строгого порядка, или memcpy перехлёстывающихся диапазонов).
5. Многопоточные гонки.
1. Неопределённость времени компиляции.
Например, берём любую сомнительную арифметику (например, (-1)>>1 или 1<<100) и используем как константы времени компиляции.
Нарушение ODR, опять же.
2. Низкоуровневые проблемы, связанные с нарушением алиасинга и гонками чтения-записи — всё тот же i++ + i++
3. Огромный класс проблем с неинициализированными и повреждёнными переменными (включая гонки конструкторов статических объектов, нулевые указатели, кривая адресная арифметика, стрельба по памяти)
4. Нарушение контрактов (например, std::map с компаратором, не удовлетворяющим аксиоматике строгого порядка, или memcpy перехлёстывающихся диапазонов).
5. Многопоточные гонки.
А где нибудь есть список всех случаев UB со ссылками на стандарт?
Может от самого комитета?
Например:
— Изменение скалярного объекта между двумя точками следования более одного раза
— разыменование нулевого указателя
— переполнение знакового целочисленного
— Использование неинициализированной переменной.
и т.п.
Это en.cppreference.com/w/cpp/language/ub полный список?
И причём там «Infinite loop without side-effects»?
Может от самого комитета?
Например:
— Изменение скалярного объекта между двумя точками следования более одного раза
— разыменование нулевого указателя
— переполнение знакового целочисленного
— Использование неинициализированной переменной.
и т.п.
Это en.cppreference.com/w/cpp/language/ub полный список?
И причём там «Infinite loop without side-effects»?
А где нибудь есть список всех случаев UB со ссылками на стандарт?У C есть приложение J.2, где есть ссылки на все другие разделы стандарта, где описаны все случаи, которые стандарт помещает в этот раздел. У C++ вроде бы нету, нужно искать в стандарте по слову «undefined» (и то можно что-нибудь пропустить).
У меня есть мечта сделать подробное описание «с ментальной моделью» для каждого из них. Скажем проблемы алиасинга легко преставить себе вспомнив об 8087 или 3167, которые «висели» как независимые устройства на шине и потому попытка записать что-то в память как
float с последующим чтением как int требовала явной операции синхронизации…Это http://en.cppreference.com/w/cpp/language/ub полный список?Смеётесь, что ли? Полный список — это сотни случаев разных, а там перечислены хорошо если пара десятков.
Просто 90% (а то и 99%) всех UB споров не вызыват, все и так понимают, что «так делать низззя». Простейший пример: вызов функций с «…» и без «…» могут быть устроены радикально по разному и если вы будете вызывать функцию с «…» не включив заголовочный файл с соответствующим прототипом, то у вас программа может легко «слететь с катушек». И никто по этому поводу особо не ноет.
И причём там «Infinite loop without side-effects»?Об этом явно написано в стандарте:
4.7.2 Forward progress [intro.progress]То есть компилятор имеет право выкидывать циклы, которые «ничего не делают». Что-нибудь типа
1 The implementation may assume that any thread will eventually do one of the following:
(1.1) — terminate,
(1.2) — make a call to a library I/O function,
(1.3) — perform an access through a volatile glvalue, or
(1.4) — perform a synchronization operation or an atomic operation.
[ Note: This is intended to allow compiler transformations such as removal of empty loops, even when termination cannot be proven. — end note ]
for (int i=0;i<1000000;i++)
; // Do nothing
for (;;)
; // Do nothing
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Неопределенное поведение в C++