On Wed, Sep 19, 2012 at 2:20 AM, Vicente J. Botet Escriba < vicente.botet@wanadoo.fr> wrote:
Le 19/09/12 01:47, Giovanni Piero Deretta a écrit :
On Tue, Sep 18, 2012 at 10:45 PM, Eugene Yakubovich <eyakubovich@gmail.com>wrote:
On Mon, Sep 17, 2012 at 11:24 AM, Giovanni Piero Deretta
It has been suggested that coroutine::self be removed an have a thread
specific object. I strongly disagree with this option. First of all it
will
make it too easy to break type safety:
typedef this_coroutine<int(int)> this_coro;
typedef this_coroutine<void()> that_coro;
coroutine<int(int)>([]{ that_coro::yield(); // oops compiles fine, UB at runtime. });
This is a good point. I now think I'd prefer type safety here so I agree that using a thread specific object is bad.
Help me convince Oliver then ;).
Hi,
I didn't know that Oliver was for the thread specific object design.
I'm not sure the alternative I proposed is the best one. Compile type safety is too important to be lost. Unfortunately I don't have a solution that is type safe and that avoid to pass an additional parameter to the coroutine function.
Why do you feel it is important not to pass the additional parameter?
Oliver, I don't know if you can take care of both alternatives, so that we can experiment with. If it is not the case, it seems that maintaing the self/caller parameter is safer. The thread specific design could always be built on top of actual design, isn't it?
A trivial adapter around the coroutine-fn would do it.