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

101–110 of 221 posts

Re: Modern C++ gamedev: thoughts and misconceptions

#101

Post by Jare »

leni536 wrote: post #47

I feel that most of the problems with debuggability is tooling (still). No, I do not want to debug the standard library most of the time, please let me optimize that, while I keep my part unoptimized. Hopefully modules will allow mixed optimization levels for template headers. Metaprogramming also lacks a good debugging story, but I would be happy to be proven wrong. In my opinion these are not language problems, but…

There are designs and usage choices that make the tooling problem orders of magnitude harder. You still have to use the tools you have, today, while the tools of tomorrow arrive. The debate is about what and why (some of) those choices are taken or rejected by different people.

Re: Modern C++ gamedev: thoughts and misconceptions

#102

Post by HelloNurse »

gordaco wrote: post #32
deepaksurti wrote: post #23

Earlier quoted context omitted.

> Not always, though. See every bug and exploit with C arrays ... That can also be perceived as a a flaw of the language design in that it does not allow one to write dumb, safe and fast code. Which are such languages in existence today? edit: fixed typos

I would say Java, which I suspect is bound to be a bit of an unpopular opinion here (I expect more startup people than enterprise denizens in HN); but the more I think about it, the more sure I'm that it fits the bill: - Dumb: you bet. The inclusion of lambdas has shaken things a little, but usually Java code is straightforward with little space for "cleverness". The counterpoint to this, of course, would be the meme…

Cleverness is more a function of a programmer's habits and attitude than of the language: one tries to be clever in any language.

C++ offers "efficient" ways to be clever, with varied and difficult challenges that can be addressed in relatively little difficult code; some are good or harmless (e.g. aligning struct fields to cache lines or concise towers of useful templates) and some are bad (e.g. flaky homemade not-too-smart pointers and almost-STL-compatible containers).

Java, on the contrary, facilitates the creation of large, boring and easy to read generic object-oriented tumors, that become satisfactorily clever only when they go very far (e.g. one more layer of indirection than everyone else) or reach theoretical limits (e.g. nothing left to invert control of).

Re: Modern C++ gamedev: thoughts and misconceptions

#103

Post by hhmc »

xfs wrote: post #94
danielscrubs wrote: post #72

Earlier quoted context omitted.

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…

> 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

If the compiler can enfore an invariant (constness), why cede that functionality on the hopes you can ensure it yourself?

By the same line of argumentation you should do away with the static type system.

Re: Modern C++ gamedev: thoughts and misconceptions

#105

Post by bernawil »

gordaco wrote: post #32
deepaksurti wrote: post #23

Earlier quoted context omitted.

> Not always, though. See every bug and exploit with C arrays ... That can also be perceived as a a flaw of the language design in that it does not allow one to write dumb, safe and fast code. Which are such languages in existence today? edit: fixed typos

I would say Java, which I suspect is bound to be a bit of an unpopular opinion here (I expect more startup people than enterprise denizens in HN); but the more I think about it, the more sure I'm that it fits the bill: - Dumb: you bet. The inclusion of lambdas has shaken things a little, but usually Java code is straightforward with little space for "cleverness". The counterpoint to this, of course, would be the meme…

  The inclusion of lambdas has shaken things a little
I'm curious, do you consider lambdas as more or less "dumb"? Because I consider them the dumbest, simplest and maybe best way to do polymorphism. In a way, OOP's whole shtick was about not using them and instead extend stuff with classes.

Re: Modern C++ gamedev: thoughts and misconceptions

#106

Post by gintery »

xfs wrote: post #94
danielscrubs wrote: post #72

Earlier quoted context omitted.

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…

Most people hate const at first (myself included) but once you get used to it, it really does reduces mental load. Not having to glance around is precisely the point, its not a big thing but it does help.

Re: Modern C++ gamedev: thoughts and misconceptions

#107

Post by hhmc »

xfs wrote: post #97
hhmc wrote: post #78

Earlier quoted context omitted.

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.

But the wider context here -- and the reason the changed version was presumably written -- is the accusation that folds are overcomplicated.

It's under that lens that I am criticizing the changed code.

Re: Modern C++ gamedev: thoughts and misconceptions

#108

Post by gintery »

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…

Is the code really that complex? Overly verbose, maybe, but its really not that hard to follow even for someone who doesn't know much about C++ templates.

Re: Modern C++ gamedev: thoughts and misconceptions

#109

Post by eska »

vbezhenar wrote: post #49
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...

With Java I've seen coding standards that you can use `var` only when type is obvious from declaration. For example: var person = new Person(); var car = selectCarById(carId); // Car if type is not obvious, it should be explicitly declared.

This is also common in the C++ community. Clang-tidy has an auto fix for this that can be applied to code bases.

Re: Modern C++ gamedev: thoughts and misconceptions

#110

Post by eska »

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.

If the type is not obvious one can also write

    for(Class entry : container)
This is still an uncontroversial improvement over having to typedef or use auto for the iterator.
Post reply on HN