czw., 9 gru 2021 o 17:28 Phil Endecott via Std-Proposals
<std-proposals_at_[hidden]> napisał(a):
>
> Dear Experts,
>
> I have recently been experimenting with generators for the
> first time.
>
> One issue that bothers me is inlining. For example:
>
> generator<char> g1()
> {
> for (.....) {
> co_yield x;
> if (......) g2(a);
> if (......) g2(b);
> g2(a+b);
> }
> }
>
> static ??? g2(int)
> {
> for (....) {
> co_yield ....;
> }
> }
>
> What I'm trying to convey with that pseudocode is that I've
> decomposed a largish block of code by factoring out some common
> bits into another routine. If these were functions this would be
> unproblematic; the compiler would likely inline and if it didn't
> the function call overhead would be modest. But because it's a
> coroutine, things are more complicated. Given the complexity of
> the recursive generator implementation, I don't think that there
> is any real prospect of g2 being properly inlined into g1, is
> there?
>
> What bothers me is that if I wrote g2 as a macro, it would of
> course be perfectly inlined.
>
> We don't want to find that we have a choice between (a) over-long
> functions with duplicated code, (b) macros, (c) nicely organised
> code that is slow.
>
> This makes me wonder if some special meaning for "inline" would
> be useful in the case of coroutines. An "inline coroutine" would
> become part of its parent for the purpose of e.g. creating the
> coroutine state machine.
>
> Has anyone thought about this at all? Any alternatives?
>

Basic solution is simply `co_yield g2(a)` and then make a complex
implementation in `generator<char>` that handles nested generators.
When you yield on another generator it will redirect the outer
generator `++` to this inner `++`.

>
> Regards, Phil.
>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals