Я использую Loki :: Functor для целей обратного вызова и хочу поделиться функтором (объект с подходящим operator()
определена функция-член) между двумя обратными вызовами. Этот функтор должен содержать состояние, чтобы оба колбэка видели его.
Быстрый тест показывает, что построение функтора Loki с функтором, передаваемым по значению, имеет другой результат, чем использование конструктора-указателя на функцию-член:
#include "loki/Functor.h"
struct Bar {
int x;
void inc() { ++x; }
int operator()() { return x; }
int get() { return x; }
};
Bar b;
Loki::Functor<int, Loki::NullType> f1(b);
Loki::Functor<int, Loki::NullType> f2(&b, &Bar::get);
Loki::Functor<int, Loki::NullType> f3(&b, &Bar::operator());
cout << f1() << endl; // prints '0'
cout << f2() << endl; // prints '0'
cout << f3() << endl; // prints '0'
b.inc();
cout << f1() << endl; // prints '0'
cout << f2() << endl; // prints '1'
cout << f3() << endl; // prints '1'
f2
демонстрирует, что использование указателей на функции-члены и указатель на экземпляр приводит к f1
, затем f3
предлагает себя как возможный способ разделить функтор между функторами loki.
я верю f1
относится к «семантике копирования», поддерживаемой Loki :: Functor — создается копия функтора, которая имеет новое значение для x
, в то время как f2
а также f3
делать то, что я хочу — фактический экземпляр ссылается на loki Functor и поэтому разделяется между ними.
Поэтому я хотел бы знать, если f3
это лучший способ связать один и тот же фактический экземпляр функтора Bar
до двух функторов локи (f2
& f3
), или есть лучший / более чистый способ сделать это в соответствии с f1
синтаксис?
РЕДАКТИРОВАТЬ: некоторые могут спросить, почему я использую Локи, учитывая его возраст? Он обеспечивает то, что мне нужно в ограниченной среде разработки, где глобальная статика строго запрещена (однако мне пришлось удалить синглтон Small Object из loki / Functor.h, но это было легко). С удовольствием уточню ограничения, если у кого-то есть предложения по альтернативным обобщенным библиотекам функторов.
Задача ещё не решена.
Других решений пока нет …