Здравствуйте, jazzer, Вы писали:

EP>>В случае с указателем на функцию — компилятору после инлайнинга требуется сделать constant propagation, чтобы убедится что вызов происходит по константному указателю, и только после этого встроить этот косвенный вызов.
J>Ну я поэтому специально использовал самый обычный рабоче-крестьянский -О2, а не какую-то высокоуровневую эзотерику об осьмнадцати ключах
J>Сам видишь, на -О2 все замечательно встраивается

Да, но всё же шансов на встраивание тут меньше, так как требует больше работы со стороны оптимизатора. То есть, например, если взять много подобных тестов, взять разных версий компиляторов лет за 10-15 лет, то думаю что функциональные объекты будут встраиваться намного охотней.
Вообще говоря, когда стоит подобный выбор, я стараюсь использовать именно функциональные объекты, как раз по этой причине. В каких-то же совсем некритичных местах, если bind на функцию будет выглядеть лаконичней, то так уж и быть, можно и его.

EP>>Во-вторых разница может проявится при разных опциях компилятора: -Os, max-inline-recursive-depth, не говоря уже об -Od.
EP>>Например на -Os компилятор имеет полное моральное право сгенерировать только один вариант std::transform для двух вызовов с bind'ами, отличающимися только указателями на функции, но не типами.
J>Я думаю, он то же самое способен сделать и с лямбдами, если это уменьшит код — ведь в лямбде тоже просто вызов функции, и компилятор может так и оставить там callq, не встраивая ничего.

Я о другом — когда мы например передаём в std::sort разные указатели на функции, но одинаковых типов (типы итераторов тоже одинаковые), мы получаем одну instantiation std::sort.
Если же мы передаём две лямбды — то у них будут разные типы, и соответственно у std::sort будет две instantiations. Конечно продвинутый компилятор, при -Os может догадаться их как-нибудь объединить, но это очевидно сложнее чем просто оставить одну instantiation в случае указателей на функции.

J>А может и встроить в обоих случаях, если встраивание уменьшает код.

Да, бывает и такое (причём часто ). А ещё иногда бывает что -Os делает код быстрее.

J>Тут вопрос только в том, насколько компилятор готов заморочиться — потому что, по-хорошему, для реальной минимизации кода надо компилировать несколько вариантов, а потом выбирать самый короткий. А можно просто тупо отрубить определенные классы оптимизаций, которые "обычно" раздувают код, даже если в конкретном случае они могли бы код и сдуть. Менее эффективно в смысле результата, зато быстро в сымсле скорости компиляции.

Да уж, тут прям целая оптимизационная задача.
Кстати, при оптимизации на скорость иногда имеет смысл компилировать код налету, под конкретные данные. А если возможных параметров много, и как они поведут себя на пришедших данных неизвестно — то можно натравить на них какой-нибудь оптимизационный метод, то есть делать серию сборок, и выбирать быстрейшую. Имеет смысл тогда, когда итераций много, но основная часть обрабатываемых данных остаётся неизменной (например в некоторых задачах линейной алгебры нужно умножать большую константную разряженную матрицу на разные вектора, которые вычисляются в процессе итераций).

J>(Сейчас набегут и скажут, что С++ — язык для гиков)

В нашу песочницу из других редко кто заходит