Raif wrote:
First, I was not aware you could nest a case statement in a different scope like that.
You've never met Duff's Device:
Code:
switch (count % 8)
{
case 0: do { *to = *from++;
case 7: *to = *from++;
case 6: *to = *from++;
case 5: *to = *from++;
case 4: *to = *from++;
case 3: *to = *from++;
case 2: *to = *from++;
case 1: *to = *from++;
} while (--n > 0);
}
(please note that I'm not advocating its use, this is simply for informational purposes)
Raif wrote:
What about when something goes haywire in that loop?
There's two things that help with debugging... Because you can't use locals you need to use something like what I've done, and having a struct with all the variables available from outside tells you where it is and what it's doing (the way I've done it gives you the line number...). Also, the loop can be designed in isolation and then converted to be a generator after the fact. In principal, you pretty much just need to replace every enqueue operation with a yield and all locals with members of structs.
Raif wrote:
Can you be confident other programmers will understand the generator function idiom after you've left the project?
Maintenance is basically my only concern.
Raif wrote:
If not, take the safe road and avoid it.
Oh I wouldn't put this in production code. This will sit on a shelf in my mind until a situation comes up where it's orders of mangnitude better than any of the alternatives.
Raif wrote:
The way you've written it tells me it will never be asynchronous (do one iteration per function call and return). With that in mind, you need neither generator functions nor threading, and I'm still hard-pressed to think of any case where they'd be useful enough to justify the added complexity in C.
Clearly this wouldn't be that useful for trivial cases like the one I've written, but there are situations where one iteration relies on the previous one(s) and this is basically one of the possible ways of storing that state, another being a thread or process asynchronously taking care of it and another being the construction of a state machine so multiple independant invocations can work properly.
Raif wrote:
The big idea here is that if the language was designed with something like this in mind, then its implied that you're using an understood idiom. If not, it may not be so safe to make that assumption.
I agree, but there are times when something sufficiently powerful justifies expanding the knowledge that's expected of people. Threads are a perfect example of this.