Возвращаемые значения для активных объектов
Еще в 2010 году Херб Саттер выступал за использование активных объектов вместо голых нитей в статья на доктора Добба.
Вот версия C ++ 11:
class Active {
public:
typedef std::function<void()> Message;
Active(const Active&) = delete;
void operator=(const Active&) = delete;
Active() : done(false) {
thd = std::unique_ptr<std::thread>(new std::thread( [=]{ this->run(); } ) );
}
~Active() {
send( [&]{ done = true; } );
thd->join();
}
void send(Message m) { mq.push_back(m); }
private:
bool done;
message_queue<Message> mq; // a thread-safe concurrent queue
std::unique_ptr<std::thread> thd;
void run() {
while (!done) {
Message msg = mq.pop_front();
msg(); // execute message
} // note: last message sets done to true
}
};
Класс можно использовать так:
class Backgrounder {
public:
void save(std::string filename) { a.send( [=] {
// ...
} ); }
void print(Data& data) { a.send( [=, &data] {
// ...
} ); }
private:
PrivateData somePrivateStateAcrossCalls;
Active a;
};
Я хотел бы поддерживать функции-члены с не возвращаемыми типами возврата. Но я не могу придумать хороший дизайн, как реализовать это, то есть без использования контейнера, который может содержать объекты разнородных типов (например, boost::any).
Любые идеи приветствуются, особенно ответы, которые используют функции C ++ 11, такие как std::future а также std::promise,
Решение
Это займет некоторую работу.
Сначала напиши task<Sig>, task<Sig> это std::function это только ожидает, что его аргумент движимое, не копируется
Ваш внутренний тип Messages будут task<void()>, Таким образом, вы можете быть ленивым и иметь свой task Поддерживайте только нулевые функции, если хотите.
Во-вторых, отправить создает std::packaged_task<R> package(f);, Затем он получает будущее из задачи, а затем перемещает package в вашу очередь сообщений. (Вот почему вам нужен только для перемещения std::function, так как packaged_task можно только переместить).
Затем вы возвращаете future от packaged_task,
template<class F, class R=std::result_of_t<F const&()>>
std::future<R> send(F&& f) {
packaged_task<R> package(std::forward<F>(f));
auto ret = package.get_future();
mq.push_back( std::move(package) );
return ret;
}
клиенты могут ухватиться за std::future и использовать его, чтобы (позже) получить результат обратного вызова.
Забавно, что вы можете написать действительно простую нулевую задачу только для перемещения следующим образом:
template<class R>
struct task {
std::packaged_task<R> state;
template<class F>
task( F&& f ):state(std::forward<F>(f)) {}
R operator()() const {
auto fut = state.get_future();
state();
return f.get();
}
};
но это смехотворно неэффективно (в упакованной задаче есть вещи для синхронизации), и, вероятно, требуется некоторая очистка. Я нахожу это забавным, потому что он использует packaged_task только для переезда std::function часть.
Лично я столкнулся с достаточным количеством причин, чтобы хотеть задачи только для перемещения (среди этой проблемы), чтобы чувствовать, что только движение std::function стоит писать. Далее следует одна из таких реализаций. Это не сильно оптимизировано (вероятно, так же быстро, как большинство std::function впрочем) и не отлажен, но дизайн добротный
template<class Sig>
struct task;
namespace details_task {
template<class Sig>
struct ipimpl;
template<class R, class...Args>
struct ipimpl<R(Args...)> {
virtual ~ipimpl() {}
virtual R invoke(Args&&...args) const = 0;
};
template<class Sig, class F>
struct pimpl;
template<class R, class...Args, class F>
struct pimpl<R(Args...), F>:ipimpl<R(Args...)> {
F f;
R invoke(Args&&...args) const final override {
return f(std::forward<Args>(args)...);
};
};
// void case, we don't care about what f returns:
template<class...Args, class F>
struct pimpl<void(Args...), F>:ipimpl<void(Args...)> {
F f;
template<class Fin>
pimpl(Fin&&fin):f(std::forward<Fin>(fin)){}
void invoke(Args&&...args) const final override {
f(std::forward<Args>(args)...);
};
};
}
template<class R, class...Args>
struct task<R(Args...)> {
std::unique_ptr< details_task::ipimpl<R(Args...)> > pimpl;
task(task&&)=default;
task&operator=(task&&)=default;
task()=default;
explicit operator bool() const { return static_cast<bool>(pimpl); }
R operator()(Args...args) const {
return pimpl->invoke(std::forward<Args>(args)...);
}
// if we can be called with the signature, use this:
template<class F, class=std::enable_if_t<
std::is_convertible<std::result_of_t<F const&(Args...)>,R>{}
>>
task(F&& f):task(std::forward<F>(f), std::is_convertible<F&,bool>{}) {}
// the case where we are a void return type, we don't
// care what the return type of F is, just that we can call it:
template<class F, class R2=R, class=std::result_of_t<F const&(Args...)>,
class=std::enable_if_t<std::is_same<R2, void>{}>
>
task(F&& f):task(std::forward<F>(f), std::is_convertible<F&,bool>{}) {}
// this helps with overload resolution in some cases:
task( R(*pf)(Args...) ):task(pf, std::true_type{}) {}
// = nullptr support:
task( std::nullptr_t ):task() {}
private:
// build a pimpl from F. All ctors get here, or to task() eventually:
template<class F>
task( F&& f, std::false_type /* needs a test? No! */ ):
pimpl( new details_task::pimpl<R(Args...), std::decay_t<F>>{ std::forward<F>(f) } )
{}
// cast incoming to bool, if it works, construct, otherwise
// we should be empty:
// move-constructs, because we need to run-time dispatch between two ctors.
// if we pass the test, dispatch to task(?, false_type) (no test needed)
// if we fail the test, dispatch to task() (empty task).
template<class F>
task( F&& f, std::true_type /* needs a test? Yes! */ ):
task( f?task( std::forward<F>(f), std::false_type{} ):task() )
{}
};
это первый набросок объекта задачи только для перемещения из библиотечного класса. Он также использует некоторые вещи C ++ 14 ( std::blah_t псевдонимы) — заменить std::enable_if_t<???> с typename std::enable_if<???>::type если вы компилятор только для C ++ 11.
Обратите внимание, что void трюк возвращаемого типа содержит несколько сомнительных трюков с перегрузкой шаблона. (Можно утверждать, что это допустимо по формулировке стандарта, но каждый компилятор C ++ 11 примет его, и, скорее всего, он станет легальным, если это не так).
Другие решения