Сообщение Re[22]: Когда это наконец станет defined behavior? от 30.04.2023 9:58
Изменено 30.04.2023 10:18 rg45
Re[22]: Когда это наконец станет defined behavior?
Здравствуйте, T4r4sB, Вы писали:
TB>Ага, как и strict aliasing, переполнение знаковых итд. В языке нет механизма отслеживать нарушение этих правил. Даже санитайзер для проверки алиасинга до сих пор не запилили.
Ну так может быть это и есть объяснение, почему один сценарий объявляется UB, а другой нет? В твоем примере
P.S. Если рассматривать конкретно этот пример, то почему-то же программист написал "return l + a;", а не "return l + ll;". Вероятно, он знает, что после вызова функции bar значение объекта, адресуемого ссылкой a, должно (или может) измениться и осознанно обрабатывает этот случай?
TB>Ага, как и strict aliasing, переполнение знаковых итд. В языке нет механизма отслеживать нарушение этих правил. Даже санитайзер для проверки алиасинга до сих пор не запилили.
Ну так может быть это и есть объяснение, почему один сценарий объявляется UB, а другой нет? В твоем примере
Автор: T4r4sB
Дата: 28.04.23
у компилятора нет возможности отследить, но есть возможность гарантировать правильный результат. Да, плата за эти гарантии — потери возможности оптимизации, но надежность программы всегда имела более высокий приоритет, чем оптимизация. В добавок ко всему еще и у программиста во многих случая есть возможность переписать код так, чтоб убить обоих зайцев — и надежность, и производительность. Дата: 28.04.23
P.S. Если рассматривать конкретно этот пример, то почему-то же программист написал "return l + a;", а не "return l + ll;". Вероятно, он знает, что после вызова функции bar значение объекта, адресуемого ссылкой a, должно (или может) измениться и осознанно обрабатывает этот случай?
Re[22]: Когда это наконец станет defined behavior?
Здравствуйте, T4r4sB, Вы писали:
TB>Ага, как и strict aliasing, переполнение знаковых итд. В языке нет механизма отслеживать нарушение этих правил. Даже санитайзер для проверки алиасинга до сих пор не запилили.
Ну так может быть это и есть объяснение, почему один сценарий объявляется UB, а другой нет? В твоем примере
P.S. Если рассматривать конкретно этот пример, то почему-то же программист написал "return l + a;", а не "return l + ll;". Вероятно, он знает, что после вызова функции bar значение объекта, адресуемого ссылкой "a", должно (или может) измениться и осознанно обрабатывает этот случай?
TB>Ага, как и strict aliasing, переполнение знаковых итд. В языке нет механизма отслеживать нарушение этих правил. Даже санитайзер для проверки алиасинга до сих пор не запилили.
Ну так может быть это и есть объяснение, почему один сценарий объявляется UB, а другой нет? В твоем примере
Автор: T4r4sB
Дата: 28.04.23
у компилятора нет возможности отследить, но есть возможность гарантировать правильный результат. Да, плата за эти гарантии — потери возможности оптимизации, но надежность программы всегда имела более высокий приоритет, чем оптимизация. В добавок ко всему еще и у программиста во многих случая есть возможность переписать код так, чтоб убить обоих зайцев — и надежность, и производительность. Дата: 28.04.23
P.S. Если рассматривать конкретно этот пример, то почему-то же программист написал "return l + a;", а не "return l + ll;". Вероятно, он знает, что после вызова функции bar значение объекта, адресуемого ссылкой "a", должно (или может) измениться и осознанно обрабатывает этот случай?