Is this setjmp/jongjmp usable legal?

[88888 Dihedral]

Playeræ–¼ 2013å¹´1月4日星期五UTC+8上åˆ2時11分15秒寫é“：

I'm not quite familiar with setjmp/longjmp (and neither with macros either) but I was trying to make something similar to this "yielding return" construct from C#, namely: when a function X "yields returns" some value everything happens like it has actually returned that value; however the state (local vars, IP) is saved, so that when X is called again it starts execution in the next statement after the last "yield return".



Is this a portable legal solution, as long as I keep local variables volatile:

1 #include <stdio.h>

2 #include <setjmp.h>

3 #define STATE_FUNC static jmp_buf _env; static int first_time = 1; if (first_time) first_time = 0; else longjmp(_env, 1)

4 #define yield(X) do { if (!setjmp(_env)) return X; } while(0)

5

6 int next_integer()

7 {

8 STATE_FUNC;

9 while(1) {

10 yield(1);

Interesting yields here, well in K&R and ANSI C90,
there were no yields.

But that was trivial to use static vars and labels
to implement yields and iterators.

 

[Nick Keighley]

Comments are more useful than line numbers for that purpose, in my
experience.


Well, yes, but the ex commands supported by vi are a pretty powerful
system; the command needed for this case wasn't very complicated, but
I've known many people who were only moderately familiar with vi who
would not have been able to figure out how to do it.


I've used many text editors other than 'vi' which had no method I could
use to remove the line numbers that was any faster than manually going
to each line and deleting them.

I've used editors with a "column select" and cut that made it fairly
easy

 

[Keith Thompson]

(snip)

Note: you should not display source code with line numbers; it's
inconvenient for anyone who wants to copy your code and try to
compile it. [...]
And it isn't that hard to remove them. One (ex) command in vi,

[...]
I've used many text editors other than 'vi' which had no method I could
use to remove the line numbers that was any faster than manually going
to each line and deleting them.

I've used editors with a "column select" and cut that made it fairly
easy

Yes, the existence of editors that make removing line numbers easy
has already been established. The point is that not all editors
do so.

And even with vi, where I know how to remove line numbers with
a single command (though it depends on how the line numbers are
formatted and can mess up indentation), it's an extra step that
discourages me from copy-and-pasting the code to try it myself.
Someone who's asking for help should make things as easy as possible
people trying to help.

A comment like "/* this is line 42 */", where you want to refer to
line 42, is both easier to deal with and makes that line stand out
much better than numbering *every* line.

 

[Tim Rentsch]

On 01/03/2013 02:52 PM, glen herrmannsfeldt wrote:

(snip)

Note: you should not display source code with line numbers; it's
inconvenient for anyone who wants to copy your code and try to
compile it. [...]
And it isn't that hard to remove them. One (ex) command in vi,

[...]

Yes, the existence of editors that make removing line numbers easy
has already been established. [snip elaboration]

A comment like "/* this is line 42 */", where you want to refer to
line 42, is both easier to deal with and makes that line stand out
much better than numbering *every* line.

I just don't agree with this, at least not always. Sometimes
putting in line numbers works just fine, and can work better than
putting markers in comments. In the particular example given at
the top of the thread, I wasn't bothered by the line numbers, nor
do I think comment markers would have been (for me) an improvement;
in fact probably the opposite.

I realize other people may react differently, and that is perfectly
okay - I don't expect other people will automatically like the same
things I do, or vice versa necessarily. But I have to raise an
objection when such a reaction is expressed like it's an absolute
statement, rather than just a personal or reader-dependent opinion,
which I believe is closer to the truth of the matter here.