From: williamkempf_at_[hidden]
Date: 2001-06-13 08:54:14
--- In boost_at_y..., larsbj_at_l... wrote:
> Douglas Gregor <gregod_at_c...> writes:
>
>
> | In the above case, using defer_call would be a mistake because it
is
> | going to
> | require the overhead of a virtual call and prohibit what
otherwise could be
> | inlined _very_ well.
>
> mmm... My main reason for trying out the defer_call has to do with
> thread creation (shown), and also with defering calls to be executed
> in another thread (I forgot to mention that):
>
> void some_foo(locked_queue<defer_holder> & que)
> {
> while (true) {
> defer_holder dh = que.pop();
> (*dh)();
> }
> }
>
>
> void bar() {
> ...
> }
>
> int main() {
> locked_queue<defer_holder> queue;
> thread_handle th = create_thread(&some_foo, queue);
> defer_holder dh = defer_call(&bar);
> queue.push(dh);
> ...
> }
>
>
> So the boost::function<> or the object returned from bind need to be
> packaged somehow to be able to pass it through a queue.
Bind should not do this, as it's an orthogonal concept, as pointed
out.
> So perhaps a "defer_call" that packages function objects with
> operator()() would be more suitable for Boost.Thread or boost in
> general?
Boost.Function already does this (I assume you're confused about this
because there are no virtual methods in boost::function<>, but trust
us, Boost.Function is a "deferred call" model).
Bill Kempf