Boost logo

Boost :

From: Douglas Gregor (gregod_at_[hidden])
Date: 2001-06-13 11:48:42

On Wednesday 13 June 2001 11:50, you wrote:
> Douglas Gregor <gregod_at_[hidden]> 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...)

Yes, this is what a hypothetical "bind" library would do. The problem is how
far to go with a bind library... allow binding of all arguments? Just the
first N arguments? Arguments in arbitrary positions? Reordering of arguments?
At some point it ends up becomes just as complex and costly as Lambda (won't
run on broken compilers, adds significantly to compile time, etc).
<frantically searches for someone else to write the code> wasn't Peter Dimov
working on something like this?

> | 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 return type of the actual functions that are being called as threads
> | won't be relevant, then, because the result will be eaten by
> | boost::function.
> I was not (completely) aware of this.
> | This is no less powerful than your defer_call example: the return types
> | must all be normalized to one type anyway because of static type
> | checking.
> yes.


Boost list run by bdawes at, gregod at, cpdaniel at, john at