Изучаю и конспектирую понемногу документацию. Наткнулся на Boost.Phoenix.
И не понимаю, что дает эта библиотека в сравнении с обычными лямбда-функциями, boost.lambda и boost.bind.
"Все есть функции" — ну ОК. Функиональные обертки val и ref — понятно, вместо переменной делается функция которая возвращает эту переменную или ссылку на нее.
"arg" — уже менее понятно. Что за синтаксис
int i=3;
std::cout << arg1(i) << std::endl; // prints 3
и как это увязывается с плейсхолдерами _1 _2 и т.д., при том что утверждается что arg1 и _1 это вроде как одно и то же?
"lazy statements" — вполне понятно, сделали набор функциональных объектов, эмулирующих работу обычных управляющих операторов. С квадратными скобками вместо фигурных красиво получилось
"lazy functions" — вообще непонятно, зачем это и чем обычные функции отличаются от таких?
И в целом вся библиотека для чего?
Boost.Phoenix is the most important Boost library for functional programming. While libraries like Boost.Bind or Boost.Lambda provide some support for functional programming, Boost.Phoenix includes the features of these libraries and goes beyond them.
In functional programming, functions are objects and can be processed like objects. With Boost.Phoenix, it is possible for a function to return another function as a result. It is also possible to pass a function as a parameter to another function. Because functions are objects, it’s possible to distinguish between instantiation and execution. Accessing a function isn’t equal to executing it.
В эпоху до С++11 вероятно имела некоторый смысл, сейчас при наличии лямбд и std::function мне кажется неактульной. Из той же книги:
Tip
Don’t use Boost.Phoenix to create complex functions. It is better to use lambda functions from C++11. While Boost.Phoenix comes close to C++ syntax, using keywords like if_ or code blocks between square brackets doesn’t necessarily improve readability.
Я когда-то пытался воспользоваться Boost.Phoenix для semantic action в парсере на Boost.Spririt, но код быстро стал нечитаемым, так что пришлось сделать обычный function object.
Здравствуйте, PM, Вы писали:
PM>Из уже упомянутой в той теме книги The Boost C++ libraries: PM>
PM>Boost.Phoenix is the most important Boost library for functional programming. While libraries like Boost.Bind or Boost.Lambda provide some support for functional programming, Boost.Phoenix includes the features of these libraries and goes beyond them.PM>
Вот, в документации к бусту тоже несколько раз упоминается что Phoenix это какой-то "шаг вперед" по сравнению с лямбдами и функицональными объектами. А в чем он, этот шаг? Я не то чтобы использовать ее хочу, а скорее понять мысли разработчиков. Может быть есть таки что-то такое еше более высокого уровня чем лямбды, чего я не понимаю?
(кстати за ссылку спасибо, у меня была оффлайн версия книги — оказывается она устарела, в ней нет phoenix и еще много чего, а я только сейчас это понял)
PM>
In functional programming, functions are objects and can be processed like objects. With Boost.Phoenix, it is possible for a function to return another function as a result. It is also possible to pass a function as a parameter to another function. Because functions are objects, it’s possible to distinguish between instantiation and execution. Accessing a function isn’t equal to executing it.
Это же обычный std::function<> тоже умеет? Или нет?
Здравствуйте, x-code, Вы писали:
XC>Вот, в документации к бусту тоже несколько раз упоминается что Phoenix это какой-то "шаг вперед" по сравнению с лямбдами и функицональными объектами. А в чем он, этот шаг? Я не то чтобы использовать ее хочу, а скорее понять мысли разработчиков. Может быть есть таки что-то такое еше более высокого уровня чем лямбды, чего я не понимаю?
Могу предположить, что более 10 лет назад, когда создавались boost.phoenix, boost.lambda это был шаг вперед по сравнению с определением функциональных объектов. Я думаю, что с появлением поддержки C++11 в популярных компиляторах, часть библиотек в Boost утратили свою актуальность (smart_ptr, regex, tuple, thread) и то же относится к boost.phoenix, boost.lambda.
PM>>
In functional programming, functions are objects and can be processed like objects. With Boost.Phoenix, it is possible for a function to return another function as a result. It is also possible to pass a function as a parameter to another function. Because functions are objects, it’s possible to distinguish between instantiation and execution. Accessing a function isn’t equal to executing it.
XC>Это же обычный std::function<> тоже умеет? Или нет?
Да, по крайне мере мне хватает встроенных лямбд и std::function для их хранения.
Здравствуйте, PM, Вы писали:
PM>Здравствуйте, x-code, Вы писали:
XC>>Вот, в документации к бусту тоже несколько раз упоминается что Phoenix это какой-то "шаг вперед" по сравнению с лямбдами и функицональными объектами. А в чем он, этот шаг? Я не то чтобы использовать ее хочу, а скорее понять мысли разработчиков. Может быть есть таки что-то такое еше более высокого уровня чем лямбды, чего я не понимаю?
PM>Могу предположить, что более 10 лет назад, когда создавались boost.phoenix, boost.lambda это был шаг вперед по сравнению с определением функциональных объектов. Я думаю, что с появлением поддержки C++11 в популярных компиляторах, часть библиотек в Boost утратили свою актуальность (smart_ptr, regex, tuple, thread) и то же относится к boost.phoenix, boost.lambda.
C++14. В C++11 лямбды мономорфные, в отличие от полиморфных бустовских (и lambda, и phoenix).
Здравствуйте, x-code, Вы писали: XC>И в целом вся библиотека для чего?
Я, честно говоря, почти ей не пользовался. Но если я правильно понимаю, у boost.phoenix остаётся одно важное премущество — он(а) не делает type erasure, то есть результат компиляции будет максимально эффективным. Я, признаться, прямо не встречал об этом упоминания, но это возможно сделать, а в случае использования boost/std function, bind — нет. Она, кстати, написана поверх boost.proto.
Вы ещё спрашивали про boost.proto. Эта библиотека для построения embedded domain specific languages. Проще говоря, она строит синтаксические деревья для выражений типа a + b * c и ему подобных. У разработчика есть сайт http://ericniebler.com и не очень давно он давал ссылку на webarchive на несколько своих постов, где он даёт краткое введение в эту библиотеку. Рекомендую.
Здравствуйте, swingus, Вы писали:
S>Здравствуйте, x-code, Вы писали: XC>>И в целом вся библиотека для чего?
S>Я, честно говоря, почти ей не пользовался. Но если я правильно понимаю, у boost.phoenix остаётся одно важное премущество — он(а) не делает type erasure, то есть результат компиляции будет максимально эффективным. Я, признаться, прямо не встречал об этом упоминания, но это возможно сделать, а в случае использования boost/std function, bind — нет. Она, кстати, написана поверх boost.proto.
bind тоже не делает type erasure, равно как и boost::lambda.
Собственно, единственное, что его делает — это boost/std::function, и именно для этого она и создана.
Все остальное генерит свой тип, почти как полиморфные лямбды С++14.
S>Вы ещё спрашивали про boost.proto. Эта библиотека для построения embedded domain specific languages. Проще говоря, она строит синтаксические деревья для выражений типа a + b * c и ему подобных. У разработчика есть сайт http://ericniebler.com и не очень давно он давал ссылку на webarchive на несколько своих постов, где он даёт краткое введение в эту библиотеку. Рекомендую.
J>bind тоже не делает type erasure, равно как и boost::lambda.
Ага, я всё-таки прав был, если верить Скотту
...Во-вторых, лямбда-выражения как правило работают быстрее. Дело в том что std::bind захватывает и хранит указатель на функцию, поэтому компилятор имеет мало шансов встроить (inline) ее, ...
Здравствуйте, swingus, Вы писали:
S>Здравствуйте, jazzer, Вы писали:
J>>bind тоже не делает type erasure, равно как и boost::lambda.
S>Ага, я всё-таки прав был, если верить Скотту S>
S>...Во-вторых, лямбда-выражения как правило работают быстрее. Дело в том что std::bind захватывает и хранит указатель на функцию, поэтому компилятор имеет мало шансов встроить (inline) ее, ...
какое отношение это имеет к type erasure? его по-прежнему нету, в отличие от boost/std::function.
Плюс bind берет в качестве аргумента не только указатель на функцию, но и функциональный объект — а его operator() замечательно встраивается.
Плюс при стандартном использовании, когда результат bind не сохраняется куда-то надолго (что, скорее всего, приведет к type erasure, потому что будет храниться в виде function), а передается в шаблонную функцию, которая тут же и раскрывается (типа std::sort и т.п.) — я не вижу проблем со встраиванием такого вызова — оно после всех inline-преобразований должно превратиться просто в вызов функции, известной на этапе компиляции.
По крайней мере, я бы удивился, если бы компилятор не смог встроить код функции, взятой через bind.
(через полчаса)
З.Ы. Практика — критерий истины. Будем встраивать функцию f, сначала по-простому (функции gN), а потом на массиве (функции aN):
using namespace std;
using namespace placeholders;
int f(int x, int y) { return x+y; }
int __attribute__((noinline)) g1(int x, int y)
{
return f(x,y);
}
int __attribute__((noinline)) g2(int x, int y)
{
auto w = bind(f, _1, _2);
return w(x, y);
}
int __attribute__((noinline)) g3(int x, int y)
{
auto w = bind(&f, _1, y);
return w(x);
}
int __attribute__((noinline)) g4(int x, int y)
{
auto w = bind(&f, x, _1);
return w(y);
}
// теперь массивint arr[] = {1,2,3,4,5,6,7,8,9};
int __attribute__((noinline)) a1(int y)
{
transform( begin(arr), end(arr), begin(arr), [y](int& a){ return f(a, y);} );
return arr[0];
}
int __attribute__((noinline)) a2(int y)
{
transform( begin(arr), end(arr), begin(arr), bind(f, _1, y) );
return arr[0];
}
Здравствуйте, jazzer, Вы писали:
J>Плюс при стандартном использовании, когда результат bind не сохраняется куда-то надолго
я бы это назвал "нестандартным" использованием bind (результат bind имеет unspecified type, так что напрямую работать хлопотно), лично я обычно его сразу кладу в function. еще в студии были баги, если попытаться сразу применить результат bind к аргументу
J>Так что либо Скотт неправ, либо ты читаешь что-то сильно устаревшее.
я думаю, что цитата вырвана из контекста и имеется в виду type erasure
вот тут немного исследовали встраиваемость std::function, результаты были печальные, только clang хорошо себя повел http://rsdn.ru/forum/cpp/5658184.flat
Здравствуйте, jazzer, Вы писали:
то S>>Ага, я всё-таки прав был, если верить Скотту S>>
S>>...Во-вторых, лямбда-выражения как правило работают быстрее. Дело в том что std::bind захватывает и хранит указатель на функцию, поэтому компилятор имеет мало шансов встроить (inline) ее, ...
J>[...] J>Так что либо Скотт неправ, либо ты читаешь что-то сильно устаревшее.
Уверен что современные компиляторы легко оптимизируют подобные косвенные вызовы.
Думаю имелось в виду что шансов встроить указатель на функцию меньше (а не "мало"), так как очевидно код привязан не к типу, а к значению указателя.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Уверен что современные компиляторы легко оптимизируют подобные косвенные вызовы.
У современного компилятора столько же шансов соптимизировать std::bind(), сколько виртуальную функцию.
EP>Думаю имелось в виду что шансов встроить указатель на функцию меньше (а не "мало"), так как очевидно код привязан не к типу, а к значению указателя.
Вот как раз Скотт говорит, что хранится указатель на функцию, так что это "очевидно" совсем не очевидно.
Здравствуйте, swingus, Вы писали:
EP>>Уверен что современные компиляторы легко оптимизируют подобные косвенные вызовы. S>У современного компилятора столько же шансов соптимизировать std::bind(), сколько виртуальную функцию.
Какой конкретно bind? С указателем на функцию внутри?
Это смотря как считать. Результат bind часто используется в контекстах, где передаётся в шаблон функции, который где-то внутри сразу его вызывает (смотри пример jazzer'а), то есть грубо говоря статический полиморфизм. И после инлайнинга, легко доказывается что этот указатель на функцию константен.
А виртуальные функции практически всегда используются для динамического полиморфизма, при котором в месте вызова статически не известно какой конкретно метод нужно вызывать (хотя есть эвристические методы типа PGO).
И уж шансов соптимизировать подобный bind на порядки выше чем виртуальный вызов.
А вот если сравнивать с тем bind'ом, который принимает функциональные объекты — то тут вообще не о чём спорить, так как какой конкретно код нужно вызывать закодировано в типе возвращаемого объекта.
EP>>Думаю имелось в виду что шансов встроить указатель на функцию меньше (а не "мало"), так как очевидно код привязан не к типу, а к значению указателя. S>Вот как раз Скотт говорит, что хранится указатель на функцию, так что это "очевидно" совсем не очевидно.
Так я и говорю, что здесь код привязан к значению, то есть хранится значение. Более того, для разных входных указателей на функции, но с одинаковым типом, получится одинаковый тип результата bind
Здравствуйте, uzhas, Вы писали:
U>Здравствуйте, jazzer, Вы писали:
J>>Плюс при стандартном использовании, когда результат bind не сохраняется куда-то надолго U>я бы это назвал "нестандартным" использованием bind (результат bind имеет unspecified type, так что напрямую работать хлопотно), лично я обычно его сразу кладу в function. еще в студии были баги, если попытаться сразу применить результат bind к аргументу
Наоборот, это самое что ни на есть стандартное использование — передача во всякие std::transform/for_each/accumulate...
Даже в С++98 стандартные байндеры использовались именно для таких случаев, никакого обобщенного хранилища типа function не было тогда.
J>>Так что либо Скотт неправ, либо ты читаешь что-то сильно устаревшее. U>я думаю, что цитата вырвана из контекста и имеется в виду type erasure
U>вот тут немного исследовали встраиваемость std::function, результаты были печальные, только clang хорошо себя повел U>http://rsdn.ru/forum/cpp/5658184.flat
Здравствуйте, swingus, Вы писали:
S>Ну хранение указателя на функцию — это и есть реализация type erasure для функций.
это как? указатель на функцию инициализируется в таком коде точно так же, как это было бы в лямбде — и там, и там все известно на этапе компиляции.
А если такой указатель к тебе пришел неизвестно откуда, то как бы ты его не использовал — в байнде или в лямбде — ничего встраиваться не будет, очевидно.
>> Так что либо Скотт неправ, либо ты читаешь что-то сильно устаревшее. S>Это из аннотации к новой книге.
Ну печально, чо
S>А ассемблерный код в данном случае ничего не доказывает. Точно также компилятор может заменить виртуальные вызовы на прямые в простых случаях.
Так это не какие-то особенно простые случаи, это самый обычный сценарий использования bind — передача в алгоритм.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Уверен что современные компиляторы легко оптимизируют подобные косвенные вызовы.
именно.
EP>Думаю имелось в виду что шансов встроить указатель на функцию меньше (а не "мало"), так как очевидно код привязан не к типу, а к значению указателя.
Если значение указателя известно во время компиляции, то я не вижу вообще никакой разницы между лямбдой и байндером — компилятор встроит и там, и там.
И если неизвестен — тоже: он останется неизвестным и внутри лямбды и встроен не будет ни там, ни там.
Здравствуйте, swingus, Вы писали:
S>Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>>Уверен что современные компиляторы легко оптимизируют подобные косвенные вызовы. S>У современного компилятора столько же шансов соптимизировать std::bind(), сколько виртуальную функцию.
И столько же, сколько лямбду.
А именно — если компилятору что-то известно во время компиляции, это будет использовано независимо от того, в байнде это, в лямбде или в виртуальном вызове по известному во время компиляции типу. А если неизвестно, то и лямбда никак тут не поможет.
EP>>Думаю имелось в виду что шансов встроить указатель на функцию меньше (а не "мало"), так как очевидно код привязан не к типу, а к значению указателя. S>Вот как раз Скотт говорит, что хранится указатель на функцию, так что это "очевидно" совсем не очевидно.
Ассемблер тебя не убедил? Ты там видишь хранящийся указатель на функцию где-нибудь?
Здравствуйте, jazzer, Вы писали:
EP>>Думаю имелось в виду что шансов встроить указатель на функцию меньше (а не "мало"), так как очевидно код привязан не к типу, а к значению указателя. J>Если значение указателя известно во время компиляции, то я не вижу вообще никакой разницы между лямбдой и байндером — компилятор встроит и там, и там.
Во-первых разница в том что именно компилятору приходится встраивать.
В случае с функциональным объектом — ему нужно только встроить обычный вызов, грубо говоря даже не прикладывая никаких усилий для доказательства того, что вызваться будет одна и та же функция. Есть тип, и с этим типом связанна конкретная функция, другой быть не может.
В случае с указателем на функцию — компилятору после инлайнинга требуется сделать constant propagation, чтобы убедится что вызов происходит по константному указателю, и только после этого встроить этот косвенный вызов.
Во-вторых разница может проявится при разных опциях компилятора: -Os, max-inline-recursive-depth, не говоря уже об -Od.
Например на -Os компилятор имеет полное моральное право сгенерировать только один вариант std::transform для двух вызовов с bind'ами, отличающимися только указателями на функции, но не типами.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>В случае с указателем на функцию — компилятору после инлайнинга требуется сделать constant propagation, чтобы убедится что вызов происходит по константному указателю, и только после этого встроить этот косвенный вызов.
Ну я поэтому специально использовал самый обычный рабоче-крестьянский -О2, а не какую-то высокоуровневую эзотерику об осьмнадцати ключах
Сам видишь, на -О2 все замечательно встраивается
EP>Во-вторых разница может проявится при разных опциях компилятора: -Os, max-inline-recursive-depth, не говоря уже об -Od. EP>Например на -Os компилятор имеет полное моральное право сгенерировать только один вариант std::transform для двух вызовов с bind'ами, отличающимися только указателями на функции, но не типами.
Я думаю, он то же самое способен сделать и с лямбдами, если это уменьшит код — ведь в лямбде тоже просто вызов функции, и компилятор может так и оставить там callq, не встраивая ничего.
А может и встроить в обоих случаях, если встраивание уменьшает код.
Тут вопрос только в том, насколько компилятор готов заморочиться — потому что, по-хорошему, для реальной минимизации кода надо компилировать несколько вариантов, а потом выбирать самый короткий. А можно просто тупо отрубить определенные классы оптимизаций, которые "обычно" раздувают код, даже если в конкретном случае они могли бы код и сдуть. Менее эффективно в смысле результата, зато быстро в сымсле скорости компиляции.
(Сейчас набегут и скажут, что С++ — язык для гиков)
Здравствуйте, 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>(Сейчас набегут и скажут, что С++ — язык для гиков)
Здравствуйте, jazzer, Вы писали:
J>З.Ы. Практика — критерий истины. Будем встраивать функцию f, сначала по-простому (функции gN), а потом на массиве (функции aN): J>... J>
В случае с bind есть indirect call, хотя transform не был заинлайнен в обоих случаях.
Очевидно что локально, внутри самого transform, больше доступной информации в случае с лямбдой. И вот эта локальная разница, может привести к разному результату, хотя глобально во время компиляции доступна вся информация в обоих случаях.