Date: Thu, 09 Dec 2021 16:27:52 +0000
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?
Regards, Phil.
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?
Regards, Phil.
Received on 2021-12-09 10:27:56