On Thu, Sep 20, 2012 at 12:45 PM, Oliver Kowalke <oliver.kowalke@gmx.de>wrote:
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.
my information was that references are pointers but because they are not changeable after initialization the compiler can do arbitrary things with it (especially the optimizer). OK - the code could cause undefined behaviour for references.
Should bind() deny to bind to references and the coroutine-fn parameters must be pointers in this case?
no please!
Should yield() return a tuple<> instead (as in the current implementation) and bind() is not provided?
Again, I would prefer that a coroutine would allow later retrieval of the result value, but I think such a yield (or caller_t::operator()) would be fine. You should still consier having yield should return a reference to a tuple. The tuple itself should be stored on the calling coroutine operator(). And viceversa of course. Depending on the implementation, it might (or not) be more efficient. -- gpd