C or C++ for my game engine? • Hacker News Board

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

#121

Post by fizixer » Tue, Jan 19, 2016, 12:47 AM UTC

blub wrote: post #102

fizixer wrote: post #4

> I have to choose between writing duplicated code, writing a code generator, or tedious macro stuff for generic code. Code-generation all the way. Use an expressive language like python/lua/tcl/lisp/scheme to work on a higher layer than C. Two-language programming (one GC scripting, the other C) beats the heck out of C++, in terms of best of both worlds: expressivity in higher layer, performance in lower layer. C++…

Where's your proof that a mix of e.g Python and C is a particularly productive way of working? This is not the first time you make this unsubstantiated claim. The opposite of what you say is easy to argue for: two languages, twice the headaches. * first of all, you need to know TWO different languages. C is completely different from a language like Ruby or Lisp. * even if you manage to do that, you still have two bui…

Here are some examples (based on my limited experience) that hardly anyone could challenge:

- Unix philosophy and the shell utilities (bash + C)

- Emacs (lisp + C)

- Python scientific stack (Python + C/FORTRAN) (Heck even Google had to offer tensorflow in two interfaces, Python and C++. If they were going to offer a Python interface anyway, they could make their life 100x easier by implementing the backend in C instead of C++).

- git (bash + C)

As for 2 languages, twice the headaches, not if your 1 language is a multi-paradigm monster called C++. I'm not really sure if this used to be the mainstream advice when C++ was created but these days it's common knowledge that you should learn at least 3 to 5 different languages in order to improve your programming languages. If you can learn 3 to 5 languages, you can definitely work in 2 languages for your projects.

And by 'average joe' I don't mean any disrespect to C++ programmers. (I'm just commenting on the thinking behind the creation of C++). Quite the contrary, I have no doubt that it takes a lot more skills and hard work to program in C++ idiomatically than in C. Unfortunately, IMO, a lot of that skill and hard work is spent managing with the "accidental complexity" of the language, and not the "inherent complexity" of the project.

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

#122

Post by girvo » Tue, Jan 19, 2016, 2:00 AM UTC

dikaiosune wrote: post #30

girvo wrote: post #2

I agree wholeheartedly with most of this post, but ended up coming to a different conclusion to the author. I don't trust myself to write good, maintable and safe C, so instead my semi-toy game engine has been (and is being) authored in Nim instead, which I've found quite interesting. Writing safe wrappers over C-libraries is a challenge in and of itself!

Isn't Nim (and almost all of its standard library) garbage collected by default? I've been very intrigued by Nim but it seems that while it has nice native/C code generation, it opts into my least favorite element of "high-level" languages.

It is, yes, however it's a bit different to most other GC-based languages in that it's soft-realtime tracing GC. In addition, you can manage your memory completely manually if you like, and in-fact thats how you interface with C libraries, which I can say from experience works much nicer than I honestly expected going in to it.

Excellent reference regarding Nim's GC and what it does differently here: http://nim-lang.org/docs/gc.html

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

#123

Post by pjmlp » Tue, Jan 19, 2016, 8:20 AM UTC

shmerl wrote: post #111

pjmlp wrote: post #87

Earlier quoted context omitted.

I am saying they are bad things, then again game developers aren't known for worrying 1s about safety anyway, specially if that implies 1ms less, even if that isn't an issue for the game being developed.

The major benefit is simply avoiding all kind of crashes which plague many games.

That is another thing that sadly many game developers usually don't care that much, given time to market.

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

#124

Post by exDM69 » Tue, Jan 19, 2016, 9:40 AM UTC

pcwalton wrote: post #119

exDM69 wrote: post #113

Earlier quoted context omitted.

> Modern compiler optimizations make what you describe not a problem anymore. Yes, it should get inlined, but I've seen this fail in a recent-ish GCC (4.6 to 4.8 or so). And there's still the issue of debug builds being slower even if the compiler works perfectly in optimized builds. Operator overloading will only work with SIMD if you write your vector class using intrinsics or SIMD extensions anyway. If you're doin…

> Yes, it should get inlined, but I've seen this fail in a recent-ish GCC (4.6 to 4.8 or so) Seems like a pretty bad GCC bug then, one that should be fixed upstream. I really dislike it when code avoids functions because of fear that they won't be inlined (or to try to work around compiler bugs to that effect), because doing this dramatically reduces code maintainability and safety in exchange for very little benefit…

GCC's inlining has been a bit brittle, especially when dealing with vector arguments, and also depending on the ABI (4x double vectors without AVX, etc). It's much better in GCC 5.x now.

I generally use always_inline for vector arithmetic functions, just to be sure. You never want to have a function call to do just a few SIMD instructions.

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

#125

Post by shmerl » Tue, Jan 19, 2016, 4:17 PM UTC

pjmlp wrote: post #123

shmerl wrote: post #111

Earlier quoted context omitted.

The major benefit is simply avoiding all kind of crashes which plague many games.

That is another thing that sadly many game developers usually don't care that much, given time to market.

Which is surprising, since games are very much human faced, and those crashes is what's considered reducing the value quite a bit. So using something like Rust should be a big boon for game developers. The only issue is that some things will still remain in the unsafe area (i.e. interfacing with graphics backend and such), but at least the code that developers control can be safer.