I'm not in games but my industry is adjacent and I have the same gripes with c++. (Which the author characterized very well.) Although build and debug times definitely are an issue regardless of the performance of the hardware.<p>I find reading C++ "standards" papers onerous and feel like they're written in a way that's deliberately inaccessible. I don't much like the idea of going to CppCon -- even if my company funded it, which maybe they would, I feel like I'd be marginalized for not using template metaprogramming, not knowing the new hotness by heart, and generally being a proponent of C-with-classes. I just feel like so much of the C++ "standards" work feels like it's led by academics who think the concerns of working programmers like me are beneath them.<p>Is there a way I can "get involved" and does my voice have any value?
So, the solution to bad debug performance is essentially YAGNI? I'm afraid that isn't a very convincing argument. If your code is several orders of magnitude slower in debug mode, then this <i>is</i> a problem. Simply downplaying this with arguments like "single-step debugging is a last resort" or "just write better tests" won't make this problem vanish. Just like exploding compile times are not solved with "just buy Incredibuild".<p>But his argument fits well with C++'s history of finding exceedingly complex solutions for simple problems. Want to have efficient matrix calculation? Well, who needs native support for matrices when you can do the same with expression templates and static polymorphism/CRTP (see: Eigen library).<p>The last section of the article says you either do nothing or you get involved. I'm afraid it is missing the obvious third option: switch to another language which actually supports your use case.
I don't want to weigh in on the rest of the content but the characterization of the game industry is pretty accurate in my experience.<p>I would expand more on the first bullet point of why game devs don't test. Tests are anti-agile and game development is extremely agile. Usually you don't know what kind of game you're making until you're done.
A few thoughts:<p>* None of the problems that have been commented on are unique to the games industry at all. Slow debug builds suck for all C++ developers and weird template meta-programming is confusing for practically everyone.<p>* He makes these broad hand-wavey statements like "individuals don't feel pain from slow compile times", or "big companies can just can throw processor power at it" to which I would say, BS. Fast iteration in C++ is really hard because of the delay and it's a big problem for everyone.<p>* "Participate more" -- isn't that exactly what people are doing on twitter? Not everyone can go to CppCon.
Whenever the response to a twitter argument is "get involved and make the change you want to see happen" you can expect absolutely nothing to change.<p>Part of this is just people complaining on a platform that over values short pithy complaints.
I am a bit puzzled by this:<p>"Before about the early 90s, we didn’t trust C compilers, so we wrote in assembly."<p>There a lot of games released during the 80's, were they really all written in assembly ?<p><a href="https://www.myabandonware.com/browse/year/" rel="nofollow">https://www.myabandonware.com/browse/year/</a><p>I don't have experience in the game industry at all, I must add.
Is Visual Studio really the best debugger?<p>Every time I use it I get really frustrated by the difficulty of entering complex instructions. The GUI is more discoverable but I find myself missing gdb ‘s functions and parser.<p>However, one thing in gdb that’s become steadily worse is the ability to evaluate STL’s operator[] and the like in optimized code, with the debugger frequently whining about inlining. It’s pretty horrible having to decipher the _m_data or whatever of various implementations.<p>I’m actually not sure if gcc is not compiling the inlines into the object code (I thought it was required by the standard) or if gdb just can’t find them.
>Epilogue (... snip ...)<p>> 1. Do nothing (...) You can deal with that by imposing rules on what is and isn’t allowed in your codebase, (...)<p>This is what everybody is already doing in gamedev<p>> 2. Get involved (...) C++ committee participation is open to everyone. (...)<p>Most game dev studios are Small or Mediums sized companies, and don't really have the time to waste in Committee meatings...
>Stop going to GDC as your one conference per year and start going to CppCon.<p>In fact the most popular CppCon video in Youtube is from Mike Acton: “Data Oriented Design and C++”
Most industry game dev is also done on top of C++ engines and libraries. I can see Go being used in the near future as the big engines offer bindings but I bet in 5-10 years the average startup is using something like C#. It is slow as beans but eventually CPU speed will make it much more reasonable for real use. The Unity engine is a good example. It has a weird easy powerful super bloated paradigm.
Maybe the QA folks are worse off in game dev companies, but they seem to be second class citizens everywhere else too. Which is a pity, since as stated they are worth their weight in gold. A developer has a mindset of how do I make this work, a QA person has a mindset of how do I make this break - they are completely complimentary.