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

C or C++ for my game engine?

crafn.kapsi.fi

Post reply on HN
Print view View original

91–100 of 125 posts

Re: C or C++ for my game engine?

#91

Post by loup-vaillant »

mikekchar wrote: post #57
unscaled wrote: post #45

Earlier quoted context omitted.

I was positively surprised by the constructiveness of the article itself. You'd usually get Linus' style rant about how C++ sucks so bad and C is the epitome of simplicity and design. I wholeheartedly agree with you that both languages are lacking, and I'm also waiting until Rust or another language grows mature enough to replace both of them in most cases. But I think most of the main points you describe as impossib…

I agree with your depiction of C++. In fact, one of the benefits of C++ is that it is convenient to use stack allocation rather than heap allocation. This can really simplify memory management. The trick is that you have to choose a different idiom for your idiomatic C++ ;-). The trick is to always know who owns the memory and to never allocate memory in libraries. You use dependency injection, always pass by referen…

> one of the benefits of C++ is that it is convenient to use stack allocation rather than heap allocation.

Not quite. With its destructors (and the RAII that come with them), C++ makes it easy to follow a scoped discipline. Allocations are easily scoped, but they don't necessarily happen on the stack.

Strings and vectors for instance, are typically allocated on the heap, assuming you're using the default allocator (which most people do anyway). While this is convenient and make things simpler, that's quite the runtime overhead, and causes latency problems similar to those of a genuine garbage collector (malloc() and free() aren't exactly constant time).

> never allocate memory in libraries

Now that can reduce the number of allocations in a program. Note that this also rules out most of the STL: its containers call their (possibly user defined) allocator themselves.

Re: C or C++ for my game engine?

#92

Post by loup-vaillant »

jbb555 wrote: post #53

Excellent article. I'm not sure I agree with all the points, but none of them are stupid or necessarily wrong. It's a very constructive argument. I've been thinking for a while that the problem with C++ is that 100 decisions have been made both in the library & language and in "best practice" that all individually are good, but the combined effect has been unfortunate. I'm not quite getting from the article why you c…

> I'm not quite getting from the article why you can't write in the C "subset" of C++ and add in a few of the more helpful parts of C++ though.

I think this is because of C++ name mangling, which prevents the creation of a quick and dirty reflection system. And maybe compilation times, which must be higher since the compiler has to deal with all of C++, even if you don't.

Re: C or C++ for my game engine?

#93

Post by unscaled »

crafn wrote: post #83
unscaled wrote: post #45

Earlier quoted context omitted.

I was positively surprised by the constructiveness of the article itself. You'd usually get Linus' style rant about how C++ sucks so bad and C is the epitome of simplicity and design. I wholeheartedly agree with you that both languages are lacking, and I'm also waiting until Rust or another language grows mature enough to replace both of them in most cases. But I think most of the main points you describe as impossib…

Good that I succeeded at avoiding ranting. I find it really hard to keep from throwing absolutes. Almost everything is possible with C++, that's true. Some things require a lot of engineering though. Like full program reflection, fast debug builds, and fast (below 5s) builds. Funny that you mention the decoupling of state and logic, because I see that as a non-issue in C. State is a struct, logic is a function. There…

You've said most of your build time was linking, so wouldn't you get the same build times with C? Templates would slow your build time a lot though, so they come with a price. C++ would never beat C on build times, but C never came close to Pascal, back in the day, and I'm pretty sure C# still beats the guts out of C with hands tied. :)

> Funny that you mention the decoupling of state and logic, because I see that as a non-issue in C.

I beg to differ. Decoupling logic and raw data is not an issue in C, but state is not the same as raw data. You may have the same state data duplicated in memory (e.g. an index), and there's also the issue of representation of state which is not portable (e.g. pointers, particular data structure). You also have pointers to functions (logic) in your data if I understood you right.

With C++ (or any sufficiently high level language) you can easily abstract away the difference between state and raw data. If you've got function pointers or pointers to instances of logic objects (which is a must if you don't want to litter your code with long switch clauses), you could save them as type IDs or something akin to that.

You might be programming something very different, but so far most good C code I've seen was thoroughly objected-oriented. Not in the sense it religiously followed the 3 pillars of OOP, but in the sense it coupled structs with several functions that have been meant to use on solely with these structs and sometimes employed polymorphism by embedding function pointers in these structs.

All of that is much easier to do with C++ classes, and if this is all you wanted (and you don't think you need proper separation of data from bone fide state), you can have a code that would refresh the vtable pointer in memory, and would sure be more straightforward than manually updating function pointers all over the place.

> It currently lacks safety and proper compression, so if I get serious about it I'll probably make all network data go through validation functions, which helps with both compression and handling hostile data.

Validation is nice, but you can't foresee every weird way your data could be shaped. It's very easy to miss one small corner. That's why you see several security engineers going around these threads dissing C. :)

Re: C or C++ for my game engine?

#94

Post by mikekchar »

loup-vaillant wrote: post #91
mikekchar wrote: post #57

Earlier quoted context omitted.

I agree with your depiction of C++. In fact, one of the benefits of C++ is that it is convenient to use stack allocation rather than heap allocation. This can really simplify memory management. The trick is that you have to choose a different idiom for your idiomatic C++ ;-). The trick is to always know who owns the memory and to never allocate memory in libraries. You use dependency injection, always pass by referen…

> one of the benefits of C++ is that it is convenient to use stack allocation rather than heap allocation. Not quite. With its destructors (and the RAII that come with them), C++ makes it easy to follow a scoped discipline . Allocations are easily scoped, but they don't necessarily happen on the stack. Strings and vectors for instance, are typically allocated on the heap , assuming you're using the default allocator…

It is quite possible that I'm out of date (haven't used C++ in anger for the better part of a decade), but local variable allocations have always historically been on the stack. Just don't use new. Arrays will be allocated on the stack as long as they are fixed length.

And yes, this rules out the STL :-(

Re: C or C++ for my game engine?

#95

Post by krisdol »

flohofwoe wrote: post #61

Completely agree, this is why most game developers use only a subset of C++ as "C with classes", and at the end of that thought process some are going back to C completely (I haven't made the jump yet though, but have been pondering this for at least 2 years). What I still like about C++: - user-provided code called when an "object" goes out of scope - operator overloading sometimes makes sense - simple template-meta…

Most are not writing their own engines anymore.

In this day of mobile and web gaming, indie developers everywhere, and game engines like Unity and UE4 being so accessible, I think more game developers are writing games in Java, JavaScript, C#, and other garbage collected languages -- not to mention "visual programming" of Unity and UE4.

If you're writing a game engine in C/C++ today you're probably never going beyond the desktop Windows platform.

Re: C or C++ for my game engine?

#96

Post by krisdol »

crafn wrote: post #76
golergka wrote: post #51

You speak about perfomance a lot, but do you actually have it as an important requirement, or is it just fun problem to tackle as programmer? In modern game development, it's usually the latter — most hobby game projects don't have art assets detailed enough to be slow on platforms where your end-users actually will play your game. I make games in Unity/C#, and yes, of course it's slower than a custom C solution. But…

The need for high performance meets with my creative interests. (But I also have technical interest in making the engine). I also value the ability of being able to implement extraordinary features to the engine in a whim, which is hard with large general use engines. I agree that there is a class of games that can be easily implemented with a prebuilt engine, but this is not one of them.

>I agree that there is a class of games that can be easily implemented with a prebuilt engine, but this is not one of them.

I'm sure everything from minecraft and Dwarf Fortress through Battlefield 4 could have been implemented in a prebuilt engine.

Re: C or C++ for my game engine?

#97

Post by jbb555 »

exDM69 wrote: post #84
spoiler wrote: post #66

Earlier quoted context omitted.

For exceptions: - A bit unpredictable (hard to optimize) - Introduce a lot of exit points which are hard to find - They deviate from the "pay what you use," since they generate some extra code - They can introduce some nasty performance penalties (I experienced this myself a few yeas back, the compilers might be smarter these days, maybe) About the stdlib: There's a "myth" that often times the stdlib/stl is slow and…

Most C++ compilers these days should have zero cost exception handling, meaning that the non-exceptional path should be free. This works by making the compiler add exception handler data to the executable file, ie. telling where the catch() blocks are. When an exception is thrown, the stack trace is analyzed and the appropriate catch handler is found by searching for the return addresses in the exception handler data…

The cost is that you have to ensure that all your code is exception safe unless you are extremely careful to ensure that exceptions are only thrown in places you've expected and coded for.

Exception safe code is both difficult to write correctly and often has a significant run time cost.

Re: C or C++ for my game engine?

#98

Post by nly »

exDM69 wrote: post #85
nly wrote: post #24

A good article, but what disturbs me is that the author, while obviously aware of relatively good C++ and programming practices, has somehow arrived in a place where he discounts essentially all of C++s core competencies... like claiming RAII is "far from optimal", that exception safety is "a constant mental overhead", and that copy and move semantics involve writing "a lot of code". These are fairly outrageous claim…

> like claiming RAII is "far from optimal", that exception safety is "a constant mental overhead", and that copy and move semantics involve writing "a lot of code". These are fairly outrageous claims I agree with the OP on all three counts. I don't think RAII is very nice (python-esque with-statement would be nicer IMO), exception safety is really a mental overhead unless you restrict exceptions to a minimum and the…

> I don't think RAII is very nice (python-esque with-statement would be nicer IMO)

You can implement Pythons 'with' statement in C++ with almost the same syntax and exactly the same terseness. This shouldn't be surprising, since C++'s value-semantic constructor-destructor mechanism is simply more general and fundamental.

> copy-assign-move semantics do add a bit of work to every class you introduce.

Only if you fill your objects with multiple dumb C pointers to other objects ad nauseam. If you embrace value semantics and smart pointers you almost never have to write any of the "rule of 5", and when you do it's straightforward. Simple rule: a class should never contain handles or pointers to more than a single resource. Composition handles the rest.

Re: C or C++ for my game engine?

#99

Post by golergka »

krisdol wrote: post #96
crafn wrote: post #76

Earlier quoted context omitted.

The need for high performance meets with my creative interests. (But I also have technical interest in making the engine). I also value the ability of being able to implement extraordinary features to the engine in a whim, which is hard with large general use engines. I agree that there is a class of games that can be easily implemented with a prebuilt engine, but this is not one of them.

>I agree that there is a class of games that can be easily implemented with a prebuilt engine, but this is not one of them. I'm sure everything from minecraft and Dwarf Fortress through Battlefield 4 could have been implemented in a prebuilt engine.

Not sure about Battlefield 4 — this kind of graphics pipeline modification is hardly available in Unity.

Re: C or C++ for my game engine?

#100

Post by w0utert »

golergka wrote: post #90
crafn wrote: post #76

Earlier quoted context omitted.

The need for high performance meets with my creative interests. (But I also have technical interest in making the engine). I also value the ability of being able to implement extraordinary features to the engine in a whim, which is hard with large general use engines. I agree that there is a class of games that can be easily implemented with a prebuilt engine, but this is not one of them.

> I agree that there is a class of games that can be easily implemented with a prebuilt engine, but this is not one of them. This "class of games" includes more or less everything that a single developer without a very costly art department can produce. If your game can not be implemented with a prebuilt engine, it's really something extraordinary.

I think it's pretty clear from the article that using an off-the-shelf engine is not an option for the author, because it doesn't satisfy his interest in building game engines ;-)

That said, I agree with your previous comment about performance. Rarely, if ever, should using one programming language over another limit the performance of any game so much that it would severely affect what you can and can not do gameplay- or feature wise. Unless you use some highly dynamic scripting language that fundamentally doesn't fit the problem domain, of course (I wouldn't write a 3D engine in Python or Ruby, for example).

I can somewhat understand some of the other arguments of choosing C over C++ (primarily build times), but for the most part the problems the author has with C++ appear to be philosophical. You can have almost everything you want in C++, if you're prepared to use it differently depending on your requirements. In terms of performance, it really is true that optimization only pays off for small sections of your code, so it doesn't make any sense to switch languages for that. You can most definitely make an extremely efficient data-oriented entity-component system in C++ without going having to jump through any hoops, for example.

Post reply on HN