Timeline for The "blub paradox" and c++
Current License: CC BY-SA 3.0
12 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| May 19, 2016 at 16:53 | comment | added | Jules | @MikeDeSimone - your thoughts about the validity of jmp_buf after a return are valid. Specifically, in the scheme you describe, calling longjmp(a, 1) will make the b buffer invalid. There isn't any way of achieving this in standard C/C++, but if you're willing to mess around with stacks you can achieve it, but it's very compiler/hardware dependent, and may well amount to writing a (simple) operating system. You probably just want to use threads and queues and be done with it... | |
| May 31, 2011 at 7:04 | comment | added | Jon Purdy | @Mike: setjmp and longjmp utterly break quite a lot of things in C++, unfortunately. I've looked into this sort of thing. Of course, I'd wager there are a number of ways to implement generators/coroutines in C++, some more sane than others. | |
| May 10, 2011 at 10:08 | comment | added | Mike DeSimone | @shuttle: (continued) The thing is, I don't know if the jmp_bufs are even valid after a return. Or how to pass an exception out of the generator function up to the caller. @Xeo: *THUD* durr... @Mehrdad: import antigravity. In my defense, I'd like to point out that even though goto is considered harmful, it is the basis upon which if, while, and switch are based. switch's nasty fall-through effects are entirely because it's really just a table-lookup goto. | |
| May 10, 2011 at 10:03 | comment | added | Mike DeSimone | @shuttle: First, you'd have to define some kind of generator class, with at least a forward iterator API. Initially, it would setjmp(a) where it was and call the generating function (a virtual method of the generator?). When that function called yield, the yielded value would be stored in the object, then setjmp(b) and longjmp(a, 1) would be used to save the spot and return to the original caller, which would return the yielded value. When called again to get the next value, it would longjmp(b, 1) to get back where it was. When the generator function exits, it calls longjmp(a, 2). | |
| May 10, 2011 at 6:16 | comment | added | Xeo | @Mehrdad: xkcd ftw. :) | |
| May 10, 2011 at 6:05 | comment | added | user541686 | @Xeo, @Mike: xkcd.com/292 | |
| May 10, 2011 at 5:18 | history | migrated | from stackoverflow.com (revisions) | ||
| May 10, 2011 at 5:06 | comment | added | Xeo | *gets out his rifle* - *aims at @Mike* - *BANG* | |
| May 10, 2011 at 4:47 | comment | added | shuttle87 | @Mike DeSimone, can you elaborate (breifly) on how you'd attempt a solution with setjmp and longjmp? | |
| May 10, 2011 at 4:29 | comment | added | Mike DeSimone | I know I'll get shot for this, but if I absolutely had to implement generators in C++, I'd have to use ... setjmp and longjmp. I have no idea how much that breaks, but I guess exceptions would be the first to go. Now, if you'll excuse me, I need to go reread Modern C++ Design to get that out of my head. | |
| May 10, 2011 at 4:12 | comment | added | Nathan Ernst | I can't even begin to think how difficult it would be to create generators in C++ given C++2003. C++2011 would make it easier, but still non-trivial. Working routinely with C++, C# and Python, generators are easily the easily the feature I miss the most in C++ (now that C++2011 has added lambdas). | |
| May 10, 2011 at 3:57 | history | answered | wilhelmtell | CC BY-SA 3.0 |