Изучаю и конспектирую понемногу документацию. Наткнулся на 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>Вот как раз Скотт говорит, что хранится указатель на функцию, так что это "очевидно" совсем не очевидно.
Ассемблер тебя не убедил? Ты там видишь хранящийся указатель на функцию где-нибудь?
