On Thu, Sep 20, 2012 at 12:05 PM, Oliver Kowalke <oliver.kowalke@gmx.de>wrote:
- Why do you need to explicitly bind? If you are required to bind the arguments of the coroutine-fn anyway, the trampoline might as well do it for you.
bind() in the sense to get the address. with the address I can store new values in the variable.
I understand that. What I'm saying is that bind can't rebind a reference parameter.
- As you described, you need to provide an alternate interface (i.e. get())
get() should not be provided
how would a nested fetch the passed parameters then? Being able to yield from nested calls is the whole point of stackful coroutines.
- Tying the caller_t to an object in the coroutine stack (the parameters), makes it very hard to move the caller object to another coroutine. This is important to implement pipelines, where yield does not return to the caller but the next coroutine in the pipeline.
let us keep the library simple - chains of coroutiens will causes many problems
pipelines seems a killer feature of coroutine library, preventing a future addition seems a bad choice.
How would you exactly rebind references?
references are pointers == addresses - in the case I get the address of the pointer and store tat this place the address of the new value
references are not pointers the c++ . They are aliases; there might or might not be an address somewhere in memory representing the reference, depending on compiler version, optimization level and calling convention. In the sniped below, for example, on a modern calling convention, x will be passed via a register. You can't maningfully get the address of a register. The register might be spilled on the stack when needed, but the stack slot location need not be stable and the compiler may assume that the content won't be changed by the user code.
int i = 0, j = 0; coroutine<void(int&)> coro([&](caller_t& caller, int& x) { caller.bind(x); assert(&x == &i); // ok caller.yield(); assert(&x == &y); // ????? });
coro(i); coro(j);
caller.bind(x); // get address of the reference of x which contains the address of i
references are not objects, you cannot get a pointer to a reference.
caller.yield(); // in this call I store the address of j at the address of reference of x.
there is no such a thing :( -- gpd