Re: [boost] [WG21 mailing] N4453 Resumable expressions

On Wed, Oct 14, 2015 at 11:42 PM, Robert Ramey wrote:

On 10/13/15 12:32 PM, Vinícius dos Santos Oliveira wrote:

...

2015-04-15 10:27 GMT-03:00 Niall Douglas :

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4453.pdf

...

revision 1 (p0114r0) is available: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0114r0.pdf

I looked at this briefly and found it intriguing. But I have a couple of questions.

Suppose I use something like Boost.Coroutine and declare the function which calls it as constexpr.

Now this means that the constexpr stack is implemented at compile time and not at all at runtime. So how is not a "stackless" co-routine? How is it different than this proposal. Given this, why is this proposal even necessary?

I'm not exactly sure what you are proposing with constexpr in this situation, but I think this will help. The problem is determining the memory needed for objects that must be "kept-alive" across resumption points. Stackful implementations allocate another stack of arbitrary size, whereas stackless implementations allocate memory for specific frame(s) that can be resumed. If the code is written like standard stack based code AND a stackless implementation is desired, compiler support is needed to determine which objects need to go into the allocated frame. I don't think its possible for a C++ function at compile-time to probe a function, even if constexpr, and ask "how large will its frame be?". However, it IS possible to write "stackless" code in C++03, but the programmer must ensure that objects needed across a resumption point are allocated in some other object (so it does NOT look like normal stack-based code). See ASIO stackless coroutines for examples. The stackless approaches should be faster since its simply doing an indirect function call + jumping to the current location within that function, instead of changing the entire runtime stack. Although I'm sure actual timings are a bit tricky with modern processors, as usual. Lee