Re[22]: Carbon
От: Sinclair Россия https://github.com/evilguest/
Дата: 18.04.24 14:42
Оценка:
Здравствуйте, CreatorCray, Вы писали:
CC>Проблема в твоих руках
Да, действительно, потерял при копи-пейсте.

S>>я сразу считаю такого человека мастером.

CC>А при чём тут вера на слово? Этож ты считаешь а не тот человек.


CC>А где тебе написали конкретно что "UB — ерунда"?

Ну, например, поставили фейспалм на простое утверждение "UB, из которого язык состоит чуть менее, чем полностью".
Вот я вижу, что интовая арифметика используется примерно в каждой первой программе. То есть если покрасить исходный код более-менее любого проекта в красный там, где "возможно UB", то его будет больше, чем не красного.
CC>Всё всегда оценивается по практическому выхлопу.
Отож.
CC>Если ударяться в странные конструкции и потом бороться со странностями compile time вычислений — то гемора будет побольше.
Что вы называете "странными конструкциями"? Мы кагбэ просто взяли сложение и сравнение — чо уж тут странного-то?
Compile-time вычисления сами по себе штука хорошая, поскольку позволяют сильно улучшить перформанс программ без потери общности. Те самые zero-cost abstractions, ради которых люди и выбирают C++ вместо менее упоротых языков.
CC>Если придерживаться KISS и писать просто и строго по делу, не растекаясь шаблонами по шаблонам — таких проблем не будет.
Ооо, мне нравится ваш задор. Давайте попробуем починить UB в функции, написанной просто и строго по делу, безо всяких шаблонов:
long avg(long a, long b, long c)
{
  return (a+b+c)/3; 
}

S>>Который никогда не допускает сравнения знаковых с беззнаковыми
CC>Постоянно и осознанно допускаю
Ну, тем более.

CC>Знакового точно никогда не было.

Хм, и как же вы это проверяете?

CC>Беззнаковое осознанно используется в имплементации длинной математики.

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

CC>Не ударяюсь в метапрограммирование. См ниже.

Метапрограммирование тут совершенно ни при чём.
S>>template is_max — просто очень компактный пример, иллюстрирующий проблему.
CC>Проблема твоя в compile time вычислениях, которые работают совсем не так как реальная машина, под которую генерится код.
Ничего подобного. Проблема — вовсе не в compile time, а в том, как компилятор трактует UB. Как раз у вас в предыдущей попытке compile-time вычисления прошли "честно", и получили правильный результат.
А перенос вычислений в рантайм заставил сработать оптимизацию, которая воспользовалась UB в полном соответствии со стандартом языка.

CC>Это архитектурный баг компиляторостроителей, который можно починить но никто не станет, ибо пуристы упрутся рогом.

Это интересная гипотеза, но она не подтверждается практикой.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.