avva: (Default)
[personal profile] avva
(эта запись будет интересна только программистам и сочувствующим)

Интересная запись в блоге проекта LLVM о том, почему неопределенное поведение в стандарте C - полезная штука. Я знал эти аргументы теоретически (что неопределенное поведение позволяет компилятору более агрессивно оптимизировать код), но о подробных примерах никогда не задумывался:

Например:
  • если i - целая переменная с знаком, то компилятор может считать "i+1 > i" (или более сложное выражение, которое сводится к этому) автоматически истинным, несмотря на то, что для i==INT_MAX переполнение может сделать i+1 отрицательным. Если бы стандарт обязывал имплементацию C строго соблюдать "очевидную" логику переполнения, как это делает, например, Джава, то компилятор не смог бы почти никогда сделать эту оптимизацию.

    Подчеркну: дело тут не только в том, что стандарты C не обязывают имплементацию использовать 'дополнительный код' (two's complement) для представления отрицательных целых чисел. Даже если все имплементации используют это представление - что де-факто верно в современном мире - и даже если бы по другим причинам это представление было бы обязательным согласно стандарту, все равно может быть полезным оставить результат INT_MAX+1 неопределенным, а не "очевидным" - в точности по причине, объясненной в предыдущем абзаце. Эту довольно тонкую идею я недостаточно хорошо понимал, кажется.

  • Последствия обращения к NULL-указателю не определены. В Джаве такое обращение гарантированно кидает исключение, и в этом несомненно есть много своих преимуществ; но как следствие этого, компилятор не может менять порядок вычисления других выражений относительно обращения к указателю. Например, если на Джаве написано что-то вроде: "c = a.b; c+= 5;", то компилятор не может сгенерировать код, который сначала поместит в c 5, а потом добавит содержимое a.b. Потому что если a==NULL, то исключение должно произойти до того, как в c что-то помещено. А C/C++ таких гарантий не дает, поведение неопределенное, поэтому компилятор может изменить порядок вычисления. В данном дурацком примере это ничему не поможет, но бывают случаи, когда это может сильно ускорить вычисление.

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

Update: исходную запись почему-то удалили; я пока заменил своей копией.

Date: 2011-05-12 08:08 pm (UTC)
From: [identity profile] avva.livejournal.com
Это библиотека, а не язык, но I take your point :)

Date: 2011-05-12 08:26 pm (UTC)
From: (Anonymous)
Language design is library design. — Bjarne Stroustrup
Library design is language design. — Andrew Koenig

Date: 2011-05-13 09:17 am (UTC)
From: [identity profile] gdy.livejournal.com
Вам не хочется несколько раз подумать, как вы относитесь к UB, чтобы понять, хотели ли бы вы работать над одним проектом (http://avva.livejournal.com/2323823.html) с таким человеком как вы? )

December 2025

S M T W T F S
  123 4 56
78 9 10 11 1213
1415 1617181920
21 22 23 24 2526 27
28293031   

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Dec. 29th, 2025 07:45 am
Powered by Dreamwidth Studios