Boost logo

Boost :

From: williamkempf_at_[hidden]
Date: 2001-06-13 12:53:28


--- In boost_at_y..., larsbj_at_l... wrote:
> Douglas Gregor <gregod_at_c...> writes:
>
> | > OR... all such object need to f.ex. be repackaged into
function<void>
> | > before being passed to the queue. (it that even allowed?)
> |
> | Perhaps some examples would help. Here's some of what
Boost.Function can do:
>
>
> Ok, I do not have any problems with this.
>
> [snip]
>
> Note that I wanted to use "defer_call" to bind _all_ arguments.
>
> so in essence what I wanted is:
>
> function<void> f(bind_all(&foo, arg1, arg2, ... , arglast));
>
> Perhaps _this_ would be something for boost then... (the lambda lib
> can be used of course, but it is a tidbit more complex...)

I expect there will be a Boost solution. The LL is the best solution
in that it handles this and a whole lot more very elegantly, but it
is going to tax todays compilers (and in fact won't work on all
compilers, MSVC being the biggest flop here). So a lighter weight
Boost.Bind would still likely be a good idea. I *thought* there was
such a beast in the Files section and I know that several people are
interested in this. All that's needed is to elevate interest enough
that someone gets the job done. Are you volunteering? ;)

> | For your example with the queue of threads to start, you would
have
> | to decide
> | on a common return type for the boost::function objects (most
likely
> | void).
>
> Supposed to be an examble with a worker thread that gets fed
functions
> to run, but the result is the same.

The Boost.Threads library is going to use Boost.Function for this.
In fact, that was the catalyst that led to Boost.Function.
Boost.Function will be used both as the "thread procedure" called
when executing a thread, as well as the "work procedure" used by
planned thread pool and thread queue concepts. The assumption of
both Boost.Threads and Boost.Function is that binding and other
adaptions will be handled by some other library.

Bill Kempf


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk