Pull to refresh

Comments 24

Если мне не изменяет память — в новых плюсах же есть лямбда выражения (читай — анонимные функции).
Совершенно верно. Однако мы сейчас живем — все еще — в «переходный период», когда твой продукт должен компилироваться при помощи gcc от 3.6 и выше, а также — вижаком от 2005 и дальше. Какие уж там лямбда выражения…

Новый стандарт — на мой вкус, опять же — великолепен, но по-настоящему вкусить его можно будет через 2-3 года.
Скажите, а почему это продукт должен компилироваться древними версиями компиляторов?
В моем случае — потому, что иначе его не соберет сборочная ферма для какой-нибудь RHEL 5.0, которая, хоть и древняя как **** мамонта, но все еще активно используется в production.

Для меня это просто входное условие — извне: код должен поддерживаться широким кругом компиляторов.
Ну что ж, не повезло вам, сочувствую =( А то просто вы это так написали, как будто это прямо общее правило какое-то…
Например, это входит в требования к продукту. Так бывает.
Когда я вижу такие вещи то еще больше счастлив что пишу на C++11 =)
Извините, но судя по комментарию, вы ни русский, ни с++ толком не знаете :(
О, я тоже запятую пропустил =)
Ого, да Вы, судя по всему, экстрасенс ) Определяете знание C++ и русского языка по одному комментарию — здорово!
Вообще-то, MaximKy прав. Я не вижу, как из его комментария можно вывести его уровень владения C++, учитывая, что он только упомянул название нового стандарта, в котором есть лямбды.
И что так народ любит «class Name{ public:» писать, когда можно написать просто «struct Name{»?
Ну и статические методы тоже какаято религия не позволяет использовать?
А в чем профит? Выиграть 2 строчки кода? :)

Я просто не могу понять преимущества менее понятного:

inline_function (with_params(int a, int b))
  {
    printf("%d+%d=%d\n",a,b,a+b);
  } with_name(plus);


над понятным этим

struct {
   void operator() (int a, int b) {
       printf("%d+%d=%d\n",a,b,a+b);
   }
} plus;


К тому же функторы созданные вашим макросом могут возвращать только void, в то время как простое создание функтора сохраняет за нами возможность определить тип возвращаемого значения. :)
Похожее решение со stackoverflow:

int foo( int foo_var )
{
 /*code*/
  struct local 
  {
    static int bar( int bar_var )  
    {
      /*code*/
      return bar_var;
    }
  }
  return local::bar(foo_var);
}
Ваши функции, к сожалению, не могут возвращать значения. Вернее они возвращают значение типа класса, который они конструируют. В BOOST_LOCAL_FUNCTION уже есть решение вложенных функций.
Ага, велосипед опять на Хабре.
При чём разобранный, вроде бы, в Александреску.
У вас же GNU C, а не стандартный C++.
Обана, таки да на на g++ фокус не удался, таки придется извращатся :(
Visual Studio со включенной оптимизацией компилятора просто-напросто вырежет создание inline_function() как бесполезное. Логика компилятора понятна (все равно этот создаваемый объект никто не будет использовать, так зачем его создавать?) но представляет опасность.

Не похоже на правду, т.к. конструктор имеет side effect. Кажется, что компилятор может убрать только вызовы конструктора копирования при RVO, и это единственный случай, когда наблюдаемое поведение программы может поменяться после применение оптимизаций (конечно если нигде нет UB).
Я вижу, мало кого смущает, что этот приём — жуткий баян, известный как минимум с 1998 г. В этом году была выпущена книга Джеффа Элджера (Jeff Alger) «C++ for real programmers» (перевод надмозга — «Библиотека программиста C++»). У меня есть её русская версия в бумажном виде, в которой на странице 134 идёт описание функторов под заголовком, не поверите, «Функторы».

Не знаю, почему сия замечательная книга так непопулярна, хотя её содержание и стиль изложения позволяют назвать её шедевром, место которого на полке — аккурат рядом с «C++ modern design» любимого нами Александреску. Там про умные указатели столько всего написано, про работу с памятью, сборку мусора… Вещь!
Ух, как же она мне мозги в своё время вправила. Отличная вещь!
Sign up to leave a comment.

Articles