В работе довольно часто использую Spirit. И boost::bind тоже часто использую, основное применение -- привязка потока к функции класса. Есть ли смысл отказаться от boost::bind в пользу Phoenix-ового bind-а? Какие плюсы-минусы будут у такого решения?
Здравствуйте, __UNIX_hokum, Вы писали:
__U>В работе довольно часто использую Spirit. И boost::bind тоже часто использую, основное применение -- привязка потока к функции класса. Есть ли смысл отказаться от boost::bind в пользу Phoenix-ового bind-а? Какие плюсы-минусы будут у такого решения?
просто Bind проще и легче, и для простых вещей (типа потоков) имеет смысл использовать его.
Для более сложных лучше использовать феникс (и вместо лямбды тоже), тем более что с Boost 1.47 он будет библиотекой первого уровня.
Здравствуйте, jazzer, Вы писали:
J>Здравствуйте, __UNIX_hokum, Вы писали:
__U>>В работе довольно часто использую Spirit. И boost::bind тоже часто использую, основное применение -- привязка потока к функции класса. Есть ли смысл отказаться от boost::bind в пользу Phoenix-ового bind-а? Какие плюсы-минусы будут у такого решения?
J>просто Bind проще и легче, и для простых вещей (типа потоков) имеет смысл использовать его. J>Для более сложных лучше использовать феникс (и вместо лямбды тоже), тем более что с Boost 1.47 он будет библиотекой первого уровня.
Здравствуйте, _nn_, Вы писали:
__>Здравствуйте, jazzer, Вы писали:
J>>Здравствуйте, __UNIX_hokum, Вы писали:
__U>>>В работе довольно часто использую Spirit. И boost::bind тоже часто использую, основное применение -- привязка потока к функции класса. Есть ли смысл отказаться от boost::bind в пользу Phoenix-ового bind-а? Какие плюсы-минусы будут у такого решения?
J>>просто Bind проще и легче, и для простых вещей (типа потоков) имеет смысл использовать его. J>>Для более сложных лучше использовать феникс (и вместо лямбды тоже), тем более что с Boost 1.47 он будет библиотекой первого уровня.
__>Легче в плане производительности ?
в плане времени компиляции.
Bind очень простой, в одном файле помещается, ЕМНИП. Для простого связывания — самое то.
А Феникс навороченный, тянет за собой Proto, Fusion, MPL (скорее всего). Зато и умеет гораздо больше.
Здравствуйте, jazzer, Вы писали:
J>>>просто Bind проще и легче, и для простых вещей (типа потоков) имеет смысл использовать его. J>>>Для более сложных лучше использовать феникс (и вместо лямбды тоже), тем более что с Boost 1.47 он будет библиотекой первого уровня.
__>>Легче в плане производительности ?
J>в плане времени компиляции. J>Bind очень простой, в одном файле помещается, ЕМНИП. Для простого связывания — самое то.
Ну boost/bind состоит из 15-ти файлов.
Для простого связывания уже можно и C++0x заюзать.
J>А Феникс навороченный, тянет за собой Proto, Fusion, MPL (скорее всего). Зато и умеет гораздо больше.
Главное, чтобы в релизе все инлайнилось.
Здравствуйте, _nn_, Вы писали:
__>Для простого связывания уже можно и C++0x заюзать.
+1.
Где есть и где можно — конечно же, нужно.
J>>А Феникс навороченный, тянет за собой Proto, Fusion, MPL (скорее всего). Зато и умеет гораздо больше. __>Главное, чтобы в релизе все инлайнилось.
Ну, это еще и компилятор прожевать должен, желательно без ошибок и желательно за вменяемое время
Я вот только что напоролся на баг в GCC, сижу ковыряюсь в асме. Ломается на спирите. Включаешь оптимизацию выше О1 (конкретно, -ftree-pre) — и все перестает работать. Но все заинлайнилось, ага, так что асм очень веселый
Так что навороты — это супер, я сам их люблю и сам пишу, но может долго компилироваться и приводить к необъяснимым глюкам, потому что все это по краю возможностей компилятора.
J>>Я вот только что напоролся на баг в GCC, сижу ковыряюсь в асме.
__U>А подробности? Какая версия GCC? И в какой библиотеке эта ошибка проявляется? Интересно.
4.4
boost 1.46.1
