3 ms·

"but inelegantly." Yes. Bjarne an co. are reluctant, with good reason, to prefer to extend C++ with objects rather than syntax. The reason being: if you've goo

"but inelegantly." Yes. Bjarne an co. are reluctant, with good reason, to prefer to extend C++ with objects rather than syntax. The reason being: if you've goofed with your object design, everyone can simply ignore the object, but if you've goofed with your syntax, then you've committed everyone for all eternity. Dealing with variants via the visit() mechanism is pretty verbose, and I couldn't help but think that a nice bit of syntactic sugar wouldn't go amiss there. I was interested in the new coroutine feature in C++. That would seem like a fantastic feature to use on microcontrollers because it implements cooperative multitasking. But aye carumba, The tutorials I've seen on them have blown my mind. Overcomplicated much? I wonder if, at the end of the day, coroutines are fundamentally incompatible with the notion of a stack, and that you're always going to be trying to nail a square peg into a round hole if you try to do it.

zabzonk 5y ago
> Yes. Bjarne an co. are reluctant, with good reason, to prefer to extend C++ with objects rather than syntax. I think you either meant to elide "reluctant", or to say "syntax rather than objects".
pjmlp 5y ago
The co-routines design is actually quite similar to C# and Kotlin machinery, although many don't realise it. https://devblogs.microsoft.com/premier-developer/extending-the-async-methods-in-c/ https://devblogs.microsoft.com/premier-developer/extending-t... https://kotlinlang.org/docs/coroutine-context-and-dispatchers.html#job-in-the-context https://kotlinlang.org/docs/coroutine-context-and-dispatcher... It gets a bit easier on them thanks GC, but in the end implementing custom co-routine types is of similar complexity level.
duped 5y ago
> I wonder if, at the end of the day, coroutines are fundamentally incompatible with the notion of a stack Well it is with stackless coroutines (by definition) but they are a kind of state machine. Without a stack or heap as an escape hatch they are quite limiting (as in they aren't Turing Complete by themselves). Stackful coroutines are much more powerful and give you pretty much every kind of control flow you need (while still being strictly less powerful than continuations). It is possible for a compiler to detect whether a coroutine should be stackless or stackful, in principle at least.

zabzonk 5y ago

> Yes. Bjarne an co. are reluctant, with good reason, to prefer to extend C++ with objects rather than syntax. I think you either meant to elide "reluctant", or to say "syntax rather than objects".

pjmlp 5y ago

The co-routines design is actually quite similar to C# and Kotlin machinery, although many don't realise it. https://devblogs.microsoft.com/premier-developer/extending-the-async-methods-in-c/ https://devblogs.microsoft.com/premier-developer/extending-t... https://kotlinlang.org/docs/coroutine-context-and-dispatchers.html#job-in-the-context https://kotlinlang.org/docs/coroutine-context-and-dispatcher... It gets a bit easier on them thanks GC, but in the end implementing custom co-routine types is of similar complexity level.

duped 5y ago

> I wonder if, at the end of the day, coroutines are fundamentally incompatible with the notion of a stack Well it is with stackless coroutines (by definition) but they are a kind of state machine. Without a stack or heap as an escape hatch they are quite limiting (as in they aren't Turing Complete by themselves). Stackful coroutines are much more powerful and give you pretty much every kind of control flow you need (while still being strictly less powerful than continuations). It is possible for a compiler to detect whether a coroutine should be stackless or stackful, in principle at least.