Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Thoughts on Modern C++ and Game Dev

elbeno.com

Post reply on HN
Print view View original

91–100 of 143 posts

Re: Thoughts on Modern C++ and Game Dev

#91

Post by foldr »

mattnewport wrote: post #89
foldr wrote: post #87

Earlier quoted context omitted.

>"it's not fair that I should have to know what I'm talking about before anyone will listen to my complaining seriously". In a way it isn't fair. Most users of most programming languages don't know the language very well. So the views of these programmers are important.

I've never really bought this argument. If you want to contribute to theoretical physics and be taken seriously it's expected that you have a solid grounding in physics. This principle is generally fairly widely applied. There are people on the standards committee who represent their companies and part of their role is to speak for the needs of the 'regular' programmers at their companies who may not be as well infor…

I wasn't talking about participating directly in the standards committee (and neither was the OP).

It seems that the people who are supposed to be speaking for the regular programmers aren't doing a particularly good job.

Re: Thoughts on Modern C++ and Game Dev

#92

Post by HippoBaro »

_lbaq wrote: post #82
jokoon wrote: post #60

Earlier quoted context omitted.

You just mentioned 2 garbage collected languages on a game dev topic. I don't think they're adequate. Remember how the article was very insistent about being able to control memory and CPU resources. Those are one of the few reasons C++ is not dead. Rust? I don't see it either.

Garbage Collection is not per default something bad, even in game development, its a method of memory management, just like reference counting, or manual memory management. If you are allocating memory in your renderloop, your likely doing it wrong. Allocation outside of this critical path, well, chose your poison. GC will consume more memory, but likely to be faster when it comes to allocating and deallocating large…

Sure, you can. But then you need to manage when GC triggers. Because if you don't, you'll drop frames. And then the real choice is between C++ where there is (little) extra work getting RAII correct vs GC languages where you need to keep preventing GC up to a point where it's okay to freeze the universe.

Re: Thoughts on Modern C++ and Game Dev

#93

Post by HippoBaro »

andrewmcwatters wrote: post #58
edoo wrote: post #57

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.

You might want to stretch that estimate out. I'm running an Intel Core i5-3550 from 2012 . Furthermore, I foresee no reason to upgrade in the next 4 years. The current i5 on userbenchmark.com's front page is the 9600k, which says it's ~53% faster than my 3550. 7 years later. CPU performance is barely going anywhere. Developers should instead try to figure out how to do more with less growth. GPUs are also overpriced,…

This. When you think about it, it's an exciting time to be a dev. We need to be clever at stuff and can't just expect next-generation CPUs to make coffee for us.

Re: Thoughts on Modern C++ and Game Dev

#94

Post by dingoegret »

mattnewport wrote: post #89
foldr wrote: post #87

Earlier quoted context omitted.

>"it's not fair that I should have to know what I'm talking about before anyone will listen to my complaining seriously". In a way it isn't fair. Most users of most programming languages don't know the language very well. So the views of these programmers are important.

I've never really bought this argument. If you want to contribute to theoretical physics and be taken seriously it's expected that you have a solid grounding in physics. This principle is generally fairly widely applied. There are people on the standards committee who represent their companies and part of their role is to speak for the needs of the 'regular' programmers at their companies who may not be as well infor…

Yet somehow other heavy hitting languages are able to write standards and documentation that people can easily understand. You're not writing a damn scientific white paper and mind you white papers also have a notorious reputation in academia for being hard to penetrate because authors and students are generally not trained in technical writing. No one makes excuses for them, many wish this would change somehow. But the an organized central committee for a language has no excuses.

Re: Thoughts on Modern C++ and Game Dev

#95

Post by mattnewport »

foldr wrote: post #91
mattnewport wrote: post #89

Earlier quoted context omitted.

I've never really bought this argument. If you want to contribute to theoretical physics and be taken seriously it's expected that you have a solid grounding in physics. This principle is generally fairly widely applied. There are people on the standards committee who represent their companies and part of their role is to speak for the needs of the 'regular' programmers at their companies who may not be as well infor…

I wasn't talking about participating directly in the standards committee (and neither was the OP). It seems that the people who are supposed to be speaking for the regular programmers aren't doing a particularly good job.

It does seem that it seems that way. As someone who's pretty familiar with the current state of C++ and also has a long history in the games industry however I don't believe it actually is that way. I think the problem is more one of perception than reality but many of the complaints come from people who don't know what they don't know and I'm not sure the best way to fix that problem. The resources for them to educate themselves are freely available but a certain subset of them seem weirdly proudly stubborn about maintaining their ignorance.

I'm not personally that interested in making it my mission to help educate people who don't want to be educated but perhaps it would be a valuable way for someone to get involved. People complaining on the basis of wrong information or misunderstandings aren't likely to be taken terribly seriously though.

Re: Thoughts on Modern C++ and Game Dev

#96

Post by dagenix »

arandr0x wrote: post #71

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. 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 funde…

I find reading medical "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 Medical Conferences -- even if my company funded it, which maybe they would, I feel like I'd be marginalized for not knowing basic medical techniques, not knowing the new hotness by heart, and generally being a proponent of bleeding with leeches. I just feel like so much of the Medical "standards" work feels like it's led by academics who think the concerns of people that don't know medicine like me are beneath them.

Is there a way I can "get involved" and does my voice have any value?

Re: Thoughts on Modern C++ and Game Dev

#97

Post by honkycat »

jayd16 wrote: post #2

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. 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.

I agree /w testing game development being less of a priority than in other industries, but I feel that it is because code quality tends to take a back seat in gamedev.

Tests are NOT anti-agile, that is just dumb. I feel like a bunch of hacker news hipsters read an article about TDD 3 years ago and then said "Yep that's my opinion! Tests are bad." Despite every major software company requiring unit tests for their production code-bases. ( Hint: It's because they did the research and found tests beneficial. ) Tests enable agility.

Let's just get this out of the way now: Tests are not about catching bugs. Tests are about allowing your to safely refactor your code without breaking previously declared behavior.

Testing enables you to iterate and refactor code without constantly releasing new regressions. Testing IS code quality. If you lack tests you lack a core piece of code quality.

Re: Thoughts on Modern C++ and Game Dev

#98

Post by foldr »

mattnewport wrote: post #95
foldr wrote: post #91

Earlier quoted context omitted.

I wasn't talking about participating directly in the standards committee (and neither was the OP). It seems that the people who are supposed to be speaking for the regular programmers aren't doing a particularly good job.

It does seem that it seems that way. As someone who's pretty familiar with the current state of C++ and also has a long history in the games industry however I don't believe it actually is that way. I think the problem is more one of perception than reality but many of the complaints come from people who don't know what they don't know and I'm not sure the best way to fix that problem. The resources for them to educa…

You're very quick to call people ignorant and make uncharitable assumptions about their motivations. If your attitude is the common one, then it does seem that the opinions of regular C++ programmers are not valued by the people involved in the standards process.

Re: Thoughts on Modern C++ and Game Dev

#99

Post by arandr0x »

mattnewport wrote: post #75
arandr0x wrote: post #71

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. 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 funde…

If you want to get involved and for your voice to have value then you have to educate yourself on the subject. Unfortunately too many of my former colleagues in the games industry (I'm now in a "games adjacent" industry too) fail to do this before complaining about C++ and have the same attitude of "it's not fair that I should have to know what I'm talking about before anyone will listen to my complaining seriously".…

I've read some of the drafts and the final spec of the APIs I care most about, for example, the concurrency API (which I like a lot... I'm not solely complaining!). Do I need to watch every talk on every C++ feature before anybody in the C++ community will want to talk to me? Because I'm paid to actually write code. (I mean normally. Today my boss isn't back from vacation so you get to read my rants on HN.)

Here are the C++ subjects of interest to me:

* geometric primitives. Not having basic geometry by now is insane.

* concurrency, I think the API as it is is good, but some of the APIs around atomics (mostly the difference between compare_exchange_weak and compare_exchange_strong) are not clear, I have had to explain those to coworkers before. Why can't we have something called test_and_set like on atomic_flag that's an OK default? Also, while I perfectly understand why that's the case, atomics have deleted copy constructors and that tends to generate compiler errors. I don't get why compilers can't just generate default constructors that don't copy the atomic like all my coworkers keep having to write and potentially introduce errors in

* filesystem API, very excited for that but sort of worried it will not work on every platform and especially that it'll work terrible on windows. I have to write Windows/Linux/iOS/Android C++ so a bunch of my gripes are "the standard is inconsistently supported" and I supposed that's not the job of the standards committee to enforce... but maybe they could stop inventing new stuff for Microsoft to screw up...

* few other misc things. The fact X const& and const X& are both valid leads to every project having its own "standard" of const placement and it's not great to read, etc. not major stuff. But things that are of concerns to working programmers.

I'm not really complaining, I love C++ and being a C++ programmer and you couldn't pay me enough to go integrate idiosyncratic web frameworks. However I think you must admit that the C++ community, beyond the language itself, is a little exclusive and not super friendly to people who are not as knowledgeable as others. I have a little time to learn some of this stuff, and I would be happy to, but I will never be an expert like most of the standard committee is. Based on your message I think that makes me and my opinion not welcome? If so that's OK, but, um, there's a lot more of me than there are of them in this industry.

(edited for formatting)

Re: Thoughts on Modern C++ and Game Dev

#100

Post by pm215 »

vlovich123 wrote: post #70
deng wrote: post #33

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 is 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 Incred…

I'm curious if this comment stays true once you build debug with -Og since that's an actual optimization level now that ensures the code remains debuggable while still applying a meaningful number of optimizations. Most people turn off all optimizations in debug builds but that's silly for 99% of problems unless you're tracking down a potential compiler bug.

QEMU briefly used -Og for its debug build setting, but switched back to -O0, because in practice using -Og results in a lot more situations where gdb just says "" rather than being able to tell you the values of variables, arguments in stack backtraces, and so on. If -Og really was "optimize where possible without breaking the debug illusion", that would be great, but in my experience it absolutely was not, and now I'm pretty wary of going back and trying it again when -O0 works just fine for me for debug...
Post reply on HN