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

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

#101

Post by loup-vaillant » Mon, Jan 18, 2016, 2:09 PM UTC

mikekchar wrote: post #94

loup-vaillant wrote: post #91

Earlier quoted context omitted.

> 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 :-(

> local variable allocations have always historically been on the stack

And they still are, thank goodness. My point was that as soon as you call a constructor, all bets are off: for instance, merely declaring an std::string allocates on the heap, local variable or no. But it seems you already knew that.

I think it is important to distinguish scoped discipline from stack allocation. The former is a way to program. The later is an implementation detail (modulo performance). Your wording was a tiny bit sloppy, so I jumped at it.

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

#102

Post by blub » Mon, Jan 18, 2016, 2:21 PM UTC

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 build systems, two things to package and deploy, you need two libraries of everything (e.g: unit testing)

* you need to constantly pass information between the two worlds, which can be both performance costly and challenging from a design perspective.

* normally it's not as easy as "rewriting the slow parts in C". What if your problem is overall memory usage? What if there is no one function to rewrite?

* if you make a mistake in C (super easy), your whole app crashes.

I don't think this is the magical solution you're presenting it to be at all.

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

#103

Post by exDM69 » Mon, Jan 18, 2016, 3:00 PM UTC

jbb555 wrote: post #97

exDM69 wrote: post #84

Earlier quoted context omitted.

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.

Agreed on both accounts but the grandparent comment was talking about runtime performance penalty, which is gone (for the non-exceptional path) in modern implementations.

But yes: exception safety, even basic safety (don't leak resources or crash) is difficult, let alone strong exception safety (no side effects if exception occurs).

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

#104

Post by exDM69 » Mon, Jan 18, 2016, 3:09 PM UTC

nly wrote: post #98

exDM69 wrote: post #85

Earlier quoted context omitted.

> 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…

When I mentioned Python's with statement, that's really all I'd want. Something neater than C's "goto error" error handling, but not much more than that. I think there's constructs like this in some languages.

> Simple rule: a class should never contain handles or pointers to more than a single resource. Composition handles the rest.

The issue with this is that in the real world, you have to deal with 3rd party libraries and frameworks or even the OS syscall interface which don't follow this guideline. So you'll end up writing wrappers for all your "foreign" objects from any other libraries you use. This is a lot of work and creates impedance mismatch problems when there's no simple clearly established concept of ownership (e.g. the wrapped objects are already reference counted) or the assumptions of the library aren't friendly to C++ style semantics.

If you live in a "modern C++ only" bubble, this isn't an issue.

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

#105

Post by rootw0rm » Mon, Jan 18, 2016, 3:53 PM UTC

microcolonel wrote: post #10

rootw0rm wrote: post #8

I can sense the pitchforks coming out already! A quick disclaimer first of all: I LOVE C. Love love love it. I'm a reverser so it's my native tongue. I get as much joy from the actual creative process of coding and playing with pointers as I do from having a reliable working finished project. No offense, but I think you suffer from the same problem. You're in love with coding, so being forced to micro-manage things t…

I don't think you're addressing the concerns which made him choose C. In his case: debugging is complex, compilation is slow, name mangling is unreliable, global state is abound. He makes no mention of inline assembler, nor does he encourage premature optimization. He talks instead about a concrete problem he had: the typical performance of operations was not good enough, thus no single optimization would help much.…

1.) the comment about ASM was simply to illustrate that I doubt many highly competent coders would ever advocate doing a large project completely in C. bad example maybe, but that was my only point.

2.) complaints about debugging are invalid, sorry. we have amazing tools available these days and there's no excuse to suck at debugging.

3.) compilation is slow, he's right about that. #pragma hdrstop can help a bit there

4.) name mangling is a bitch, you can get around it by defining your exports, etc.

5.) everything else is just excuses for bad C++ code. it doesn't matter what the latest C++ style encourages you to do, what matters is writing code that works for your application.

I actually think it's awesome he's going the C route, it's just that he could probably do his project in C++ two times over in the same amount of time and I think most of his reasoning for choosing C is crap.

Didn't mean to come off like a dick so much, I wish him well, and I gotta admit alloca() is awesome

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

#106

Post by pcwalton » Mon, Jan 18, 2016, 4:17 PM UTC

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…

> I agree that the lack of incremental compiling makes it not useful for large projects at the moment.

Whoa there. Let's not exaggerate the scope of the problem. Large projects in Rust usually consist of many crates (in Servo, 150+). Rust absolutely has incremental compilation on the level of the crate, so the compilation times are similar to what you see in C++ with per-directory unity builds. This is the same story as Go, for example, and people don't say Go isn't suitable for large projects; incremental compilation isn't even on Go's roadmap.

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

#107

Post by pcwalton » Mon, Jan 18, 2016, 4:42 PM UTC

anp wrote: post #28

crafn wrote: post #25

Author here. I'm positively surprised, constructive discussion on internet! There's been some discussion about using Rust. Rust is an interesting language, and has definitely potential substituting C and C++ in some domains. The main reason I'm not so interested in using it is for game development, is because it's more complicated than C (like C++), and the complications are a bit off from what I'd want (like in C++)…

Only responding to one element of your comment -- but I think that Rust's safety features are over-marketed in my experience. The safety Rust offers is only part of a package that provides high-performance high-level abstractions over functionality that is normally very bit-twiddly in C. So far, my favorite thing about Rust is not its safety, but how easy it is to write good performance software using abstractions th…

> I think that Rust's safety features are over-marketed in my experience.

I agree with you in the sense that overfocusing on safety has led to things like Andrei's "bulging muscle" criticism, implying that Rust is especially lacking in high-level and metaprogramming features. Compared to C++ and D, it certainly does have a lower feature count in that area (although I'd argue that it's counterbalanced by the fact that Rust holds the line on strong typing for generics and hygiene for macros, whereas C++ and D don't). However, compared to most other languages Rust has very feature-rich generic programming and metaprogramming support. We're not talking "does not support generics" here; we're talking about the difference between the 95% and the 99% metaprogramming use cases. In the overall landscape of industry languages, even just having associated types makes Rust's generics system one of the most sophisticated out there. The only popular languages I can think of with more powerful generics are C++, D, Scala, and Haskell, and the first two sacrifice strong typing.

The main reason for the focus on safety is that it, combined with the lack of GC, is what actually makes Rust unique. Very few industry languages have any features unique to them, but the borrow checker is one such feature. C++ and Swift may get something like it in the future, but Rust has it now, and the entire language and ecosystem is designed around it (and the borrow checker is especially difficult to bolt on to an existing language, because it relies on strong aliasing guarantees). So it's natural that most people have focused on the zero-overhead safety when describing Rust--it's the most salient answer to the question "what can I do with Rust that I can't do with language X?"

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

#108

Post by pcwalton » Mon, Jan 18, 2016, 4:50 PM UTC

exDM69 wrote: post #81

amagumori wrote: post #31

Earlier quoted context omitted.

meh - imo, even if C++ is a ridiculously bloated beast, it has some things that are indispensable for game programming that C doesn't. vector math without operator overloading is gross. being able to have generic containers with templates is really useful, even if templates are gross. encapsulating functionality in classes is always useful, and you can get a lot of use out of inheritance without overusing it. these t…

> vector math without operator overloading is gross. Many C compilers can use normal infix operators with SIMD vectors and it will have better performance than C++ operator overloading (especially in debug builds). All you need is a typedef. typedef float vec4f __attribute__ ((vector_size (16))); vec4f a = { 1, 2, 3, 4 }, b = { 5, 6, 7, 8 }; vec4f c = a * (a + b); The typedef is slightly different for Clang, but that…

> In C++ with operator overloading it's easy to do stupid things like in-place addition (e.g. operator+= for a vec4f) or start transposing matrices in place. This will make the compiler emit memory load/store instructions when you'd want to have these values in registers.

That sounds like a failure of inlining. If you're at the point where a single stack spill makes a difference, you won't want to pay the cost of the calling convention spills either. And if you are inlining, then SROA and mem2reg will easily remove those load/store instructions. Modern compiler optimizations make what you describe not a problem anymore.

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

#109

Post by [deleted] » Mon, Jan 18, 2016, 4:50 PM UTC

exDM69 wrote: post #81

amagumori wrote: post #31

Earlier quoted context omitted.

meh - imo, even if C++ is a ridiculously bloated beast, it has some things that are indispensable for game programming that C doesn't. vector math without operator overloading is gross. being able to have generic containers with templates is really useful, even if templates are gross. encapsulating functionality in classes is always useful, and you can get a lot of use out of inheritance without overusing it. these t…

> vector math without operator overloading is gross. Many C compilers can use normal infix operators with SIMD vectors and it will have better performance than C++ operator overloading (especially in debug builds). All you need is a typedef. typedef float vec4f __attribute__ ((vector_size (16))); vec4f a = { 1, 2, 3, 4 }, b = { 5, 6, 7, 8 }; vec4f c = a * (a + b); The typedef is slightly different for Clang, but that…

[deleted]

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

#110

Post by nly » Mon, Jan 18, 2016, 4:51 PM UTC

exDM69 wrote: post #104

nly wrote: post #98

Earlier quoted context omitted.

> 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…

When I mentioned Python's with statement, that's really all I'd want. Something neater than C's "goto error" error handling, but not much more than that. I think there's constructs like this in some languages. > Simple rule: a class should never contain handles or pointers to more than a single resource. Composition handles the rest. The issue with this is that in the real world, you have to deal with 3rd party libra…

Here's an ugly hacked up version of Pythons 'with' statement:

https://gist.github.com/nlyan/7319c7b2a6328460ce9c

As for external libraries...sometimes it requires a bit of ingenuity to find that perfect 'wrap everything!' vs 'write C' balance... but it's usually not so bad if you approach the problem judiciously. unique_ptr and shared_ptr's capabilities are often underestimated in this regard for instance. Both can be used with external reference counting, the former being the most efficient.