RM
У меня примерно такой доксиген был
Size: a a a
2020 September 04
RM
Он сдох щас
RM
Мышью наводишь и нихуя не выводит почти
RM
Ищи через их поисковик опций
Ок
CC
А если
foo& operator+(decltype(foo)&&, int) модифицирует первый аргумент? Что-то соблюдается? А как компилятор это должен узнать, если не видит тела? А он практически никогда его не видитНу если есть риск, что as-if не соблюдается, то не надо такую оптимизацию
O
Ну если есть риск, что as-if не соблюдается, то не надо такую оптимизацию
Проблема в том, что такой риск есть практически всегда и проще объявить УБ, чем выкинуть тонны оптимизаций подобного рода
RM
Ну если есть риск, что as-if не соблюдается, то не надо такую оптимизацию
да этот пример с a = b + 40 хуйня, компилятор этот высер скорее всего сделает как Ofee сказал
RM
Ему эти лишние движухи не нужны
CC
Проблема в том, что такой риск есть практически всегда и проще объявить УБ, чем выкинуть тонны оптимизаций подобного рода
Хм... Мне кажется, лучше стремиться к наименьшему кол-ву UB. И вот здесь не объявлять, что это UB, а задать слева-направо, ну и из-за этого на практике компилеры наверное не будут там применять какие-либо оптимизации, если задано слева-направо, но я думаю, что мы теряем меньше в таком случае
O
Хм... Мне кажется, лучше стремиться к наименьшему кол-ву UB. И вот здесь не объявлять, что это UB, а задать слева-направо, ну и из-за этого на практике компилеры наверное не будут там применять какие-либо оптимизации, если задано слева-направо, но я думаю, что мы теряем меньше в таком случае
Мне вот кажется, что в приведённом мной примере, компиляторы не откажутся от оптимизаций. А изначальный код с присваиванием является лишь частным случаем. Я думаю, что там довольно значимое число возможных оптимизаций на реальных кодовых базах. Иначе действительно уже бы давно определили поведение в стандарте
O
Мне вот кажется, что в приведённом мной примере, компиляторы не откажутся от оптимизаций. А изначальный код с присваиванием является лишь частным случаем. Я думаю, что там довольно значимое число возможных оптимизаций на реальных кодовых базах. Иначе действительно уже бы давно определили поведение в стандарте
Блин, сам запутался в тексте
CC
Мне вот кажется, что в приведённом мной примере, компиляторы не откажутся от оптимизаций. А изначальный код с присваиванием является лишь частным случаем. Я думаю, что там довольно значимое число возможных оптимизаций на реальных кодовых базах. Иначе действительно уже бы давно определили поведение в стандарте
Мб, все просто так и думают, и оно самоподдерживается
CC
Лан, я спать, вернусь не скоро
CC
Всем споки и удачи!
M
Удачи
O
Мб, все просто так и думают, и оно самоподдерживается
Мне кажется, что код вида
bar = (foo + 42) * (foo + 42) является нормальным, пускай и не самым красивым. Равно, как мне и кажется, что он должен оптимизироваться. Проблема в том, что если мы определим поведение — компилятор не сможет оптимизировать. Мало того, что оператор должен быть инлайн, так ещё и компилятору понадобятся действительно сложные эвристики, чтобы хотя бы иногда оптимизироватьO
Лан, я спать, вернусь не скоро
RM
Мне кажется, что код вида
bar = (foo + 42) * (foo + 42) является нормальным, пускай и не самым красивым. Равно, как мне и кажется, что он должен оптимизироваться. Проблема в том, что если мы определим поведение — компилятор не сможет оптимизировать. Мало того, что оператор должен быть инлайн, так ещё и компилятору понадобятся действительно сложные эвристики, чтобы хотя бы иногда оптимизироватьДа ему насрать мне кажется, только ярые дрочеры плюсов могут заставить работать программу именно так как они хотят, а во всех остальных случаях компилятор делает что считает нужным
O
Да ему насрать мне кажется, только ярые дрочеры плюсов могут заставить работать программу именно так как они хотят, а во всех остальных случаях компилятор делает что считает нужным
Я вот не заставляю, я просто пишу нужный мне код. И он даже работает