История изменений

По-мне это порочная практика - оптимизировать говнокод в оптимальный код.

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

Он выполняет набор математических преобразований программы, каждое из которых само по себе элементарно. (Оно может быть неэлементарным в смысле реализации в коде компилятора, но в том, что оно собой представляет по смыслу – вполне).

Начиная с самых базовых трансформаций: продвижение констант, устранение лишних переменных, устранение общих подвыражений и т.п.

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

Я считаю, что проблему нужно решать именно на уровне спецификации языка.

Насколько я знаю, в крестах такие подвижки есть, и там часть терминологии undefined behavior заменяют на erroneous behavior.

«erroneous behavior - The (incorrect) behavior that the implementation is recommended to diagnose. »

Просто пока до комитетчиков что-то доходит, обычно много воды утекает.

Конкретно про арифметику знаковых чисел — я считаю, что она не должна быть UB. Это должно быть определённое поведение, даже если оно implementation-defined.

Пусть компилятор может относиться к числам как к числам в математическом смысле только в тех фрагментах программы, где он может ДОКАЗАТЬ отсутствие переполнений.

Вот тогда работа компилятора будет такой, как хочет firkax.

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

Нет, тормозит не поэтому. Это никак не связанные вещи.

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

По-мне это порочная практика - оптимизировать говнокод в оптимальный код.

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

Он выполняет набор математических преобразований программы, каждое из которых само по себе элементарно. (Оно может быть неэлементарным в смысле реализации в коде компилятора, но в том, что оно собой представляет по смыслу – вполне).

Начиная с самых базовых трансформаций: продвижение констант, устранение лишних переменных, устранение общих подвыражений и т.п.

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

Я считаю, что проблему нужно решать именно на уровне спецификации языка.

Насколько я знаю, в крестах такие подвижки есть, и там часть терминологии undefined behavior заменяют на erroneous behavior.

«erroneous behavior - The (incorrect) behavior that the implementation is recommended to diagnose. »

Просто пока до комитетчиков что-то доходит, обычно много воды утекает.

Конкретно про арифметику знаковых чисел — я считаю, что она не должна быть UB.

Пусть компилятор может относиться к числам как к числам в математическом смысле только в тех фрагментах программы, где он может ДОКАЗАТЬ отсутствие переполнений.

Вот тогда работа компилятора будет такой, как хочет firkax.

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

Нет, тормозит не поэтому. Это никак не связанные вещи.

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

По-мне это порочная практика - оптимизировать говнокод в оптимальный код.

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

Он выполняет набор математических преобразований программы, каждое из которых само по себе элементарно. (Оно может быть неэлементарным в смысле реализации в коде компилятора, но в том, что оно собой представляет по смыслу – вполне).

Начиная с самых базовых трансформаций: продвижение констант, устранение лишних переменных, устранение общих подвыражений и т.п.

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

Я считаю, что проблему нужно решать именно на уровне спецификации языка.

Насколько я знаю, в крестах такие подвижки есть, и там часть терминологии undefined behavior заменяют на erroneous behavior.

«erroneous behavior - The (incorrect) behavior that the implementation is recommended to diagnose. »

Просто пока до комитетчиков что-то доходит, обычно много воды утекает.

Конкретно про арифметику знаковых чисел — я считаю, что она не должна быть UB.

Пусть компилятор может относиться к числам как к числам в математическом смысле только в тех фрагментах программы, где он может ДОКАЗАТЬ отсутствие переполнений.

Вот тогда работа компилятора будет такой, как хочет firkax.

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

Нет, тормозит не поэтому. Это никак не связанные вещи.

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