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

Посмотрите непредвзято и хладнокровно на то, как разворачивается обсуждение исхоодного вопроса темы.

Я предложил использовать стандартные средства языка

void fn( const std::list<pf> &l, int x )
{

    std::for_each( l.begin(), l.end(),
        [&x]( pf f ){ f( x ); } );
}

Допустим, что ваш компилятор не поддерживает лямбда-выражения. Но приведенный код с лямбда выражением настолько прозрачен и поонятен, что очень легко написать функциональный объект. То есть конструкция лямбда-выражения вида [&x] эквивалентна тому, что конструктору функционального объекта нужно передать аргумент, ссылка на который или само значение будут храниться в функциональном объекте и использоваться при вызове оператор-функции.
То есть проблем никаких нет.
А что мы видим из обсуждения? Очевидно, что автор темы ранее не имел опыта написания функциональных объектов. Вместо того, чтобы такой опыт приобрести, который обязателен для каждого программиста С++, он сразу же начинает хвататься за boost! При этом в boost код достаточно сложнее для изучения, могут быть побочные эффекты, о которых вы даже не подозреваете, так как ваш компилятор может иметь собственные особенности поведения. К тому же выбудете вынуждены будете тянуть за собой кишку заголовочных файлов из boost, а также подключать к вашему проекту библиотеки boost. И все это ради замены простого функционального объекта.
Как известно, компиляторы очень быстро обновляются. например, тот же майкрософт сейчас каждый год обновляет свой компилятор. Уже анонсировали MS VC++ 11.
Представьте теперь, что в ваше проект придет новый сотрудник. Он увидет такие ваши ухищрения ради простого объекта, крайне удивится, почему такие вещи так сложно делаются, тем более, что новый компилятор предоставляет еще более эффективные и выразительные средства, и покрутит пальцем у виска, глядя на вас!
Но хуже того, теперь вы уже вынуждены будете тянуть эти библиотеки boost, функциональность которых полностью дублируется стандартными средствами. Ваш проект будет огромен и плохо управляем, так как если возникнет какая-то ошибка, то вам придется проверять все места в коде, а значит все подключаемые библиотеки, чтобы найти причину ошибки.
Фактически, ваш код превращаются в сборную солянку, где из-за каждого "чиха" подключается некая третьесторонняя библиотека, которая к тому же гарантирует, что в ней самой нет багов! Так как исправленичя вносились и вносятся и в boost. Вам трудно будет поддерживать общий стиль программирования проекта, так как вы вынуждены быдете либо использовать старые средства boost, которые уже морально устарели, либо использовать новые возможности стандарта. И эта дилемма постоянно вам будет мешать в развитии проекта.
Вам приходится предъявлять малообоснованные требования к новым сотрудникам. Ээффективность работы группы в связи с этим резко снижается, так новому сотруднику надо изучать все ваши искусственно-насаждаемые примочки. А самое главное у нового сотрудника будет отторжение ваших примочек, так как он хорошо знает, что это можно легко и более выразительно сделать с помощью стандартных средств.