

Adding a Python style yield to C++ - bad_alloc
http://www.flipcode.com/archives/Yield_in_C.shtml

======
scott_s
On POSIX systems, you can accomplish this with setjmp() and longjmp() calls.
That has the benefit of being portable across different architectures.

------
Figs
Why would you do something like this rather than just using function objects
for your generators?

    
    
        class FunctionObject {
            //internal state as member variables
          public:
            FunctionObject() { /* ... */ }
            returnType operator()() { /* Calculate next step */ }
        };

~~~
comex
Because keeping the internal state implicitly (in loops, etc) can make the
code much cleaner. See, e.g., <http://wiki.python.org/moin/Generators>

~~~
scott_s
While it may look cleaner on the surface, I don't think this sort of hackery
actually is cleaner. Are you certain this solution will work with multiple
threads? What if a signal is received during one of these calls? Are you sure
it will work across all architectures? Operating systems?

I prefer to stay within a language's semantics if possible; it reduces these
sorts of concerns. For C++, that would mean using function objects.

~~~
Figs
His code is also non-portable, and non-standard.

I haven't been able to get it to compile on my system yet, but I don't see
anywhere that he's capturing the variables on the stack, so while you may be
able to jump back to your position after one call, you'll loose whatever
parameters you passed (assuming you don't simply crash). Also, since it seems
to depend on a static variable hidden within the function, I doubt it will
work even in single threaded programs if you need multiple generators.

This is just my five minute analysis though, so grain of salt and all that.

~~~
scott_s
As I noted below, you can solve the stack problem with setjmp() and longjmp().
But that's only portable across different Unixes, not across all systems which
will have C++.

But, yes, I am in agreement: function objects are the better solution to this
problem in C++. This sort of hackery, while neat, leads to a rats nest of
problems.

------
ggchappell
Interesting, but I wonder whether Go-style "go routines" and channels would be
a better choice to implement.

First, it seems like they would be easier to write in C++. You're mostly
creating a new kind of pseudo-container (channel), instead of trying to fake
adding new syntax to the language. (Although you _do_ still need to have some
mechanism for executing a go routine, somehow ....)

Second, its a more powerful abstraction. With go routines it's not hard to
implement something with the functionality of Python-esque generators, but you
can also do fancier things that you would have a difficult time doing using
only generators.

------
te0006
This implementation: <http://www.terrainformatica.com/index.php/?p=98> is even
more portable, by applying some brutal but standards-compliant abuse to the
switch statement. The price is that you cannot have another switch statement
within your generator. Well, you can live with that if you still have some
spare if/then/else constructs in your basement.

------
ramchip
Misspelled words, geocities website, "I developed this using VC++ 6.0", and
the code is highly unportable and does not save the stack so it's borderline
useless.

Not to diminish the author, who probably has good potential, but I don't think
this article is really of HN quality.

------
Shorel
Isn't better to use a threads library for achieving this?

