|
|
|
|
|
|
by davexunit
3448 days ago
|
|
|
>Anyway, I've been programming games and game engines for several decades, and coroutines are always in the list of things that you can throw in the junk pile along with other cool things like continuations, various theoretical data structures, fancy dispatch mechanisms, events/signals, application-wide functional purity, etc. This is one of the worst outlooks on programming I've ever seen. Did you know that any control flow operator such as try/catch is really an application of continuations? |
|
|
As I said, this is about programming games, primarily in C/C++ or a related language (though applies mostly to others), not programming in general. If you enter into other high-performance domains, you will encounter the same issues. Conversely, other domains such as general application programming do not adhere to this.
Regarding try/catch, I am well aware of low-level implementations in various languages. Did you know that in most game engines, you don't use that much try/catch for this exact reason? If you're littering your game code with try/catch everywhere, you are doing something wrong. Not to say you don't have any, but there are other error handling and return methods or you just let things bubble-up and handle them there. What would you actually do in most try/catch situations deep inside a game loop outside of things where resources can leak horribly like IO?
When you're working on a game, there are of course areas you can compromise. It also as I mentioned depends on the nature of your game. I'm speaking strictly of properly designed, professional games that have to be competitive in terms of features and run at a smooth frame rate while doing many things (i.e. your average AAA console game).
In case you still doubt what I am saying, go look at GDC talks, game dev papers, etc. and you'll see the same thing. As far as someone people around here might be more familiar with as a source, I seem to recall there were multiple times Jonathan Blow mentioning exactly what I did (maybe a talk he gave at Berkley?). Anyway, the point is that as programmers we learn all these cool and fascinating things, but in game dev, you tend to have to let go of "cool" things and spin your thinking a bit towards things like predictability, performance, stability, transparency, and composeability.