Size: a a a

2020 September 04

RM

Roy Mustang in C++ Together 2.0
У меня примерно такой доксиген был
источник

RM

Roy Mustang in C++ Together 2.0
Он сдох щас
источник

RM

Roy Mustang in C++ Together 2.0
Мышью наводишь и нихуя не выводит почти
источник

RM

Roy Mustang in C++ Together 2.0
Alex Ф-ф-фэils!🌠︙
Ищи через их поисковик опций
Ок
источник

CC

Cool Cooler in C++ Together 2.0
Ofee
А если foo& operator+(decltype(foo)&&, int) модифицирует первый аргумент? Что-то соблюдается? А как компилятор это должен узнать, если не видит тела? А он практически никогда его не видит
Ну если есть риск, что as-if не соблюдается, то не надо такую оптимизацию
источник

O

Ofee in C++ Together 2.0
Cool Cooler
Ну если есть риск, что as-if не соблюдается, то не надо такую оптимизацию
Проблема в том, что такой риск есть практически всегда и проще объявить УБ, чем выкинуть тонны оптимизаций подобного рода
источник

RM

Roy Mustang in C++ Together 2.0
Cool Cooler
Ну если есть риск, что as-if не соблюдается, то не надо такую оптимизацию
да этот пример с a = b + 40 хуйня, компилятор этот высер скорее всего сделает как Ofee сказал
источник

RM

Roy Mustang in C++ Together 2.0
Ему эти лишние движухи не нужны
источник

CC

Cool Cooler in C++ Together 2.0
Ofee
Проблема в том, что такой риск есть практически всегда и проще объявить УБ, чем выкинуть тонны оптимизаций подобного рода
Хм... Мне кажется, лучше стремиться к наименьшему кол-ву UB. И вот здесь не объявлять, что это UB, а задать слева-направо, ну и из-за этого на практике компилеры наверное не будут там применять какие-либо оптимизации, если задано слева-направо, но я думаю, что мы теряем меньше в таком случае
источник

O

Ofee in C++ Together 2.0
Cool Cooler
Хм... Мне кажется, лучше стремиться к наименьшему кол-ву UB. И вот здесь не объявлять, что это UB, а задать слева-направо, ну и из-за этого на практике компилеры наверное не будут там применять какие-либо оптимизации, если задано слева-направо, но я думаю, что мы теряем меньше в таком случае
Мне вот кажется, что в приведённом мной примере, компиляторы не откажутся от оптимизаций. А изначальный код с присваиванием является лишь частным случаем. Я думаю, что там довольно значимое число возможных оптимизаций на реальных кодовых базах. Иначе действительно уже бы давно определили поведение в стандарте
источник

O

Ofee in C++ Together 2.0
Ofee
Мне вот кажется, что в приведённом мной примере, компиляторы не откажутся от оптимизаций. А изначальный код с присваиванием является лишь частным случаем. Я думаю, что там довольно значимое число возможных оптимизаций на реальных кодовых базах. Иначе действительно уже бы давно определили поведение в стандарте
Блин, сам запутался в тексте
источник

CC

Cool Cooler in C++ Together 2.0
Ofee
Мне вот кажется, что в приведённом мной примере, компиляторы не откажутся от оптимизаций. А изначальный код с присваиванием является лишь частным случаем. Я думаю, что там довольно значимое число возможных оптимизаций на реальных кодовых базах. Иначе действительно уже бы давно определили поведение в стандарте
Мб, все просто так и думают, и оно самоподдерживается
источник

CC

Cool Cooler in C++ Together 2.0
Лан, я спать, вернусь не скоро
источник

CC

Cool Cooler in C++ Together 2.0
Всем споки и удачи!
источник

M

Michael in C++ Together 2.0
Удачи
источник

M

Michael in C++ Together 2.0
источник

O

Ofee in C++ Together 2.0
Cool Cooler
Мб, все просто так и думают, и оно самоподдерживается
Мне кажется, что код вида bar = (foo + 42) * (foo + 42) является нормальным, пускай и не самым красивым. Равно, как мне и кажется, что он должен оптимизироваться. Проблема в том, что если мы определим поведение — компилятор не сможет оптимизировать. Мало того, что оператор должен быть инлайн, так ещё и компилятору понадобятся действительно сложные эвристики, чтобы хотя бы иногда оптимизировать
источник

O

Ofee in C++ Together 2.0
Cool Cooler
Лан, я спать, вернусь не скоро
источник

RM

Roy Mustang in C++ Together 2.0
Ofee
Мне кажется, что код вида bar = (foo + 42) * (foo + 42) является нормальным, пускай и не самым красивым. Равно, как мне и кажется, что он должен оптимизироваться. Проблема в том, что если мы определим поведение — компилятор не сможет оптимизировать. Мало того, что оператор должен быть инлайн, так ещё и компилятору понадобятся действительно сложные эвристики, чтобы хотя бы иногда оптимизировать
Да ему насрать мне кажется, только ярые дрочеры плюсов могут заставить работать программу именно так как они хотят, а во всех остальных случаях компилятор делает что считает нужным
источник

O

Ofee in C++ Together 2.0
Roy Mustang
Да ему насрать мне кажется, только ярые дрочеры плюсов могут заставить работать программу именно так как они хотят, а во всех остальных случаях компилятор делает что считает нужным
Я вот не заставляю, я просто пишу нужный мне код. И он даже работает
источник