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

Modern C++ gamedev: thoughts and misconceptions

vittorioromeo.info

Post reply on HN
Print view View original

111–120 of 221 posts

Re: Modern C++ gamedev: thoughts and misconceptions

#111

Post by eska »

badsectoracula wrote: post #85
KallDrexx wrote: post #39

Earlier quoted context omitted.

I wonder how wide spread dislike of "auto" is in c++ (I've seen that a few places) when the equivalent type inference has become fairly standard and preferred in other languages like C#, Rust, Go, etc...

Perhaps the people who dislike auto in C++ would also dislike the equivalent feature in other languages but they just happen to not work in them? I know i do not use any of the languages you mention, for example - and if i did, i'd explicitly write any type names.

I don't think so. auto adds some more complications in C++ than var or let in other languages. Consider "const auto& a = x" vs "auto a = x". What exactly is the type of a? It depends.

Re: Modern C++ gamedev: thoughts and misconceptions

#112

Post by golergka »

PezzaDev wrote: post #36
microtherion wrote: post #26

Earlier quoted context omitted.

> Make your code simple, dumb and verbose all the time This is a frequently encountered argument, and sure, if you look at any single line , it looks very obvious what it does. But I would argue that verbosity and lack of abstraction has severe drawbacks for a programmer's ability to understand the overall codebase , and it is disastrous for long term maintainability. You start out with 20 identical pieces of boilerp…

No coding approach will ever solve an issue caused by a lack of discipline.

Compiler constantly saves me from errors that I would've made because of "lack of discipline". That's the main purpose of various coding abstractions: to make coding errors that you would spend your "disciple" points on compilation erros instead.

Re: Modern C++ gamedev: thoughts and misconceptions

#113

Post by golergka »

PezzaDev wrote: post #17
pansa2 wrote: post #12

Earlier quoted context omitted.

> I find that the dumbest code is the best code. This is the idea behind Golang, isn’t it? That everything should be written out explicitly and not hidden behind abstractions. Some people love that, others hate it.

I'd love to try Golang, but as a game developer, the gc makes it a no go due to perf. I begrudgingly accept C# due to unity. GC is a different topic altogether, but has also always been a pain. You end writing code to avoid allocations, which at that point you ask "Why am I not just writing C++?" I also discovered GC makes bad programmers worse by allowing them not to care about ownership, enabling them to develop sy…

Some games have servers, too. And many of those are request-response (not "hold socket open") servers - which are ideally suited for GC.

Re: Modern C++ gamedev: thoughts and misconceptions

#114

Post by eska »

humanrebar wrote: post #54
winterismute wrote: post #21

Earlier quoted context omitted.

> or are you asserting that large team game dev is unique compared to other industries? Well, that would be a good question to ask to the author, since he titled the article "modern C++ gamedev" and not simply "modern C++" although to me what is discussed seems to be general enough, and "gamedev" here happens to be just the type of project the code comes from... To me, it does not look like he makes any significant c…

I have experience with large scale high performance C++, albeit not in games specifically. The recommendations in my experience are very sane, conservative even. I think at this point the onus is on critics to substantially respond to the points given. I don't think questioning credentials is particularly elucidating here. I don't see any reason the entire thesis of the article is flawed. As to the throwaway referenc…

That's the thing though. Gamedevs aren't throwing shade, it's a strawman. Look at the twitter threas mentioned in the introduction and you'll see a bunch of civil gamedev industry veterans offering constructive criticism, only to be shut down with "that's misguided" and no counter argument. It gets old fast and it's been like this for dozens of years. I'm not surprised that they stop caring.

Re: Modern C++ gamedev: thoughts and misconceptions

#115

Post by eska »

tomnj wrote: post #90

I’m often disappointed by how disrespectful people can be in programming discussions. It’s one thing to discuss tradeoffs but ridiculing peoples’ choices or speaking in absolutes is not helpful. There’s no One True Way to program.

I always wondered whether it's programming in particular that attracts a lot of people that think in only black and white, or whether it's the same in other industries as well.

Re: Modern C++ gamedev: thoughts and misconceptions

#116

Post by HelloNurse »

DethNinja wrote: post #35

I would personally use for loop without size_t. It is short and simple and works as intended, anyone can understand it.

Do you mean with decltype(std::declval().width) as the article suggests? Or with an ad-hoc typedef, e.g. Image::size_type? Or with a fixed type that should work correctly? This use of auto is particularly valuable.

Re: Modern C++ gamedev: thoughts and misconceptions

#117

Post by asveikau »

badsectoracula wrote: post #92
asveikau wrote: post #86

Earlier quoted context omitted.

These days there is also: for (auto i : vec)

Yeah, this is exactly what i dislike - unless the declaration of "vec" is somewhere close by (and assuming it isn't itself "auto" :-P) you have no idea what "i" is. Especially when that "auto i : vec" should have instead been "auto& i : vec" or "const auto& i : vec" and now you are at best wasting cycles and at worst writing to copies that will soon be discarded, ending up with a bug that can be very hard to spot.

I usually write auto &i : vec out of reflex, but left the reference part out into visually match what the parent had, with no reference. (But an iterator, so not having that issue.)

Re: Modern C++ gamedev: thoughts and misconceptions

#118

Post by eska »

neutronicus wrote: post #81
eska wrote: post #74

Earlier quoted context omitted.

This sounds unnecessarily dismissive of C programmers. I see a lot of C programmers that shit on C++ but are intrigued by Rust, e.g. Linux kernel developers allowing modules to be written in Rust.

Yes, Rust is making a smart marketing decision by capitalizing on C programmers' antipathy towards C++ (and everyone else's). I don't know that this is, ipso facto , evidence of anything about C programmers other than that they really hate C++, though.

Your view sounds very jaded to me. Maybe Rust is liked more by C programmers because they prefer its approach, rather than C++'s? Calling it a marketing ploy seems without merit to me.

Re: Modern C++ gamedev: thoughts and misconceptions

#119

Post by klyrs »

badsectoracula wrote: post #92
asveikau wrote: post #86

Earlier quoted context omitted.

These days there is also: for (auto i : vec)

Yeah, this is exactly what i dislike - unless the declaration of "vec" is somewhere close by (and assuming it isn't itself "auto" :-P) you have no idea what "i" is. Especially when that "auto i : vec" should have instead been "auto& i : vec" or "const auto& i : vec" and now you are at best wasting cycles and at worst writing to copies that will soon be discarded, ending up with a bug that can be very hard to spot.

I love the idea of auto range-based iteration but it's full of warts like the one you mention. Recently I found myself wanting an iterator over a combinatorial family.

Generation of a single solution: 3 easy lines (calling on a few hundred lines of goofy math that actually describes the structure, but that's common to all of these approaches)

Writing a for-loop to fill a std::vector of solutions -- about 10 lines of a familiar stack-walking pattern which could confuse a novice.

Making a fake container that defines a begin() and end() along with a nested iterator class: about 20 lines of necessary boilerplate, another 20 lines to replicate the stack-walking, now sprinkled about the boilerplate. The novice is completely bewildered, so we add another 10-20 lines of comments to explain it.

So I have this strong urge to keep the first two implementations in place, just to provide a gentler ramp. But I won't use the code in the end, so it would only add maintenance overhead, so a lone tear rolls down my cheek as I delete the clear, readable code.

In python, this is often as easy as changing square brackets to parentheses to change a list comprehension into a generator.

Re: Modern C++ gamedev: thoughts and misconceptions

#120

Post by humanrebar »

eska wrote: post #114
humanrebar wrote: post #54

Earlier quoted context omitted.

I have experience with large scale high performance C++, albeit not in games specifically. The recommendations in my experience are very sane, conservative even. I think at this point the onus is on critics to substantially respond to the points given. I don't think questioning credentials is particularly elucidating here. I don't see any reason the entire thesis of the article is flawed. As to the throwaway referenc…

That's the thing though. Gamedevs aren't throwing shade, it's a strawman. Look at the twitter threas mentioned in the introduction and you'll see a bunch of civil gamedev industry veterans offering constructive criticism, only to be shut down with "that's misguided" and no counter argument. It gets old fast and it's been like this for dozens of years. I'm not surprised that they stop caring.

If you are making the point that Twitter arguments are counterproductive, I agree. I will concede all objections about tone because my life is too short to get dragged into Twitter tone policing.

I do find the recommendations interesting and would like to keep the conversation about them. I would especially like to avoid gatekeeping and No True Scotsman arguments in a thread about code.

Post reply on HN