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

91–100 of 221 posts

Re: Modern C++ gamedev: thoughts and misconceptions

#91

Post by meheleventyone »

PezzaDev wrote: post #6

After years of experience writing code for games, I find that the dumbest code is the best code. It doesn't matter if it's C# or C++, whenever I've used something like reactive extensions or template metaprogramming, it has been a terrible mistake every single time. Make your code simple, dumb and verbose all the time. Avoid using any complex abstractions or any overcomplicated syntactic sugar and you'll have a codeb…

Yup, I think everyone goes through a phase of enjoying creating ‘elegant’ abstractions but you steadily learn nuts and bolts is way more preferable. That’s why I’m way more excited about Zig as a language to write games with than modern C++.

Re: Modern C++ gamedev: thoughts and misconceptions

#92

Post by badsectoracula »

asveikau wrote: post #86
MereInterest wrote: post #71

Earlier quoted context omitted.

I'd also say that using auto makes your code easier to read, especially when you are the user of generic code. Looping through a vector where you need to keep track of the iterator, for example. for(auto iter = vec.begin(); iter!=vec.end(); iter++) for(std::vector ::iterator iter = vec.begin(); iter!=vec.end(); iter++)

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.

Re: Modern C++ gamedev: thoughts and misconceptions

#93

Post by unchar1 »

I find the twitter thread to be specially sad, since I see a lot of people genuinely try to explain that compile times/familiar syntax are more important to them, but the author seems adamant that they just don't know what modern tech is and they should learn the "right" approach.

Re: Modern C++ gamedev: thoughts and misconceptions

#94

Post by xfs »

danielscrubs wrote: post #72
xfs wrote: post #65

Earlier quoted context omitted.

I love C++17 fold expression, but... Local consts are not particularly useful, especially for things like ints. Compilers know it's const, and a reader doesn't need to worry about it in a local scope. width, height usually come in pairs, so putting them on the same line is usual. nPixels and nBytes are not used more than once so they are not useful abstractions, and the pattern of `width * height * bytes_per_pixel` i…

When I read that it's const I can in my mind "drop it". It's there, I know where the value was set and don't have to skim any longer for updates. It isn't for the compiler, its for me, the next guy who has to read your code. Same thing with doing two separate things in the loop. Not only can it stop the the compiler from optimisations from time to time (the c++ compiler is very clever... but many times it gives up),…

If you as a reader need const to make sure a local variable is not changed this is usually a symptom of this function being too long to see at a glance. And quite often as code changes I do need to make some local variable non-const, and it quickly becomes annoying to fiddle back and forth enforcing const-ness of every local variable.

The argument about optimization is almost certainly premature optimization. Most of the time how you write a loop doesn't matter. You only find out what matters via profiling and refactor accordingly.

Re: Modern C++ gamedev: thoughts and misconceptions

#95

Post by bitwize »

danielscrubs wrote: post #61
Koshkin wrote: post #43

Earlier quoted context omitted.

Indeed, despite all criticisms Java as a technology is one of the best things that has happened to the software industry, next to Linux.

Java won because of its humungous and stable standard library with the full backing of Sun (and Sun was huge presence at the time). It was quite a joy to have pretty much all the functions you could ever need (not really but it felt like it at least) at your fingertips without having to do manual dependency management. As a technology it really didn't have much to give. Object Pascal was born in 1986, Ada in 1980 wit…

It wasn't just Sun, though they did the heavy lifting marketing-wise. The Apache Project also hopped on the Java train way early and produced a crapton of libraries which made developing internet applications way easier, especially for corporate schlubs who might have been previously exposed to Microsoft (or, ugh, IBM) systems but didn't have acceas to the internet foljlore Unix gurus had.

Re: Modern C++ gamedev: thoughts and misconceptions

#96

Post by klibertp »

badsectoracula wrote: post #80
klibertp wrote: post #56

Earlier quoted context omitted.

You're exaggerating. There's nothing complicated in the code - it looks straightforward to me, and I've never written an "atlas packer". The only slightly confusing line is the one before the last: I believe you should not use side-effects when unpacking the fold expression; if you need an external state, use a proper loop construct (EDIT: although, to be fair, it might be impossible in this case, unless you can reif…

Eh, no, i'm not exaggerating. I really have a hard time following the flow of the posted code. I can get a rough idea of what it is doing by ignoring most of the Modern C++-isms, but i still can't tell you with confidence that i know exactly what is going to happen (...and i'm not asking for an explanation, btw, that is besides the point :-P). I mean, sure, if i take that code and run it through a debugger - perhaps…

Well, readability is like this. It's not a property of the code alone, it's an emergent property based on both the code and your knowledge as a reader. It's very, very subjective, which our little disagreement here proves. Basically, the same code using the same feature can be both insurmountable wall of text and an elegant, readable solution - depending on your background, current knowledge, and personal taste (among other factors).

For me, this whole spread/fold feature is easy to grok, because I've worked with many similar features elsewhere. In this case, the feature looks almost identical to how `...` is handled in one of the Scheme macro systems, syntax-case (and syntax-rules, by extension)[1]. As mentioned, the use of spread on a comma operator with a side-effect is tricky and maybe too clever, but, otherwise, I don't see anything out of ordinary.

> perhaps while also crossreferencing the features it uses at cppreference.com

That's the thing - if you already knew the meaning and syntax of these features by heart, you'd find the code using them very readable. You also wouldn't need to step through it in the debugger, because there's really not much happening there in terms of control flow.

In general, "readability" is simply a bad word to use: it's too overloaded and means too many things to too many (kinds of) people. Every language can become readable to you if you put enough effort into it; and no, the amount of effort needed is also dependent more on your prior knowledge than on the language in question. So it's just too subjective to be useful as a metric for anything, unfortunately.

[1] https://docs.racket-lang.org/reference/stx-patterns.html#%28...

Re: Modern C++ gamedev: thoughts and misconceptions

#97

Post by xfs »

hhmc wrote: post #78
xfs wrote: post #65

Earlier quoted context omitted.

I love C++17 fold expression, but... Local consts are not particularly useful, especially for things like ints. Compilers know it's const, and a reader doesn't need to worry about it in a local scope. width, height usually come in pairs, so putting them on the same line is usual. nPixels and nBytes are not used more than once so they are not useful abstractions, and the pattern of `width * height * bytes_per_pixel` i…

Regardless of the induvidual merits of the changes (and I do disagree with you), it's not reasonable to say: "Folds are overcomplicated, here's a version without folds which is simpler" whilst also making a range of unrelated changes to reduce code size.

Folds are not complicated. They are just not familiar to the intended readers.

The changed version is idiomatic in image processing or similar areas that deal with pixels. Being idiomatic makes it familiar to read, and easy to change.

Re: Modern C++ gamedev: thoughts and misconceptions

#98

Post by BubRoss »

badsectoracula wrote: post #88
BubRoss wrote: post #76

Earlier quoted context omitted.

An all or nothing approach to auto ends up being silly for reasons of clarity and specificity in types. Auto with compound types makes programs easier to read and write, especially if an IDE is there to expand complex type information. If the type is small, basic, intrinsic, etc. then auto can be a hindrance.

> An all or nothing approach to auto ends up being silly I already wrote that there are some cases where auto is necessary (usually when used with more recent C++ features). > especially if an IDE is there to expand complex type information And i also already wrote that this information is not only often cumbersome to obtain but also such an IDE is often not available - e.g. in a web-based code review tool which also…

What I'm saying is that auto is very useful and not an exotic or niche feature, it just works the best when not using it in places where a type definition is already small or direct.

This usually means types that are from inside the scope of another class. Compound types that are used frequently can actually be aliased.

Also writing programs that are clear when reading from plain text is great, but I don't think that should ever be a higher priority then what it is like to work with inside an IDE. The days of writing programs with notepad are over thankfully. Languages aren't the only way to make programming easier and aren't even where the low hanging fruit is. People get caught up in languages, but tools can help much more without the herculean effort of redoing decades of work, so I lean on them whenever possible.

Re: Modern C++ gamedev: thoughts and misconceptions

#99

Post by MacSystem »

PezzaDev wrote: post #6

After years of experience writing code for games, I find that the dumbest code is the best code. It doesn't matter if it's C# or C++, whenever I've used something like reactive extensions or template metaprogramming, it has been a terrible mistake every single time. Make your code simple, dumb and verbose all the time. Avoid using any complex abstractions or any overcomplicated syntactic sugar and you'll have a codeb…

That's why even using C# I wanted to have some of C's simplicity. Keep it simple. As the Da Vinci said, "simplicity is the ultimate sophistication"

Re: Modern C++ gamedev: thoughts and misconceptions

#100

Post by BubRoss »

MaxBarraclough wrote: post #13
CamperBob2 wrote: post #8

Earlier quoted context omitted.

It's just so frustrating that they keep adding things that scratch no itch I've ever had as a programmer, while leaving out incredibly obvious things that would make my life easier and my code safer. Named parameters, for instance. It's insane that function parameters still can't be specified in any order with name=value expressions. That would have saved numerous bugs over the years, but apparently I'm the only one…

Named arguments are a good example of a simple feature that C++ still lacks, and cannot be effectively 'faked' without it being built into the language.

They can be faked to an extent with structs, but the reality of default arguments is that you have to be aware of them anyway so that you don't get behavior you don't expect. When there are default arguments you are building up assumptions and expectations that can become problems when they aren't right.
Post reply on HN