Live data from Hacker News

I write games in C (yes, C) (2016)

jonathanwhiting.com

201–210 of 288 posts

Re: I write games in C (yes, C) (2016)

#201
post #126

Earlier quoted context omitted.

I agree it shouldn't really matter if there's no C++ features in play, but I suppose third party headers could bite you if they use #ifdef __cplusplus to guard optional C++ extensions on top of their basic C interface. In that case the compiler could be dealing with dramatically more complex code when you build in C++ mode.

Maybe it is similar for the same compiler (but one should check, I suspect C could still be faster), but then there are much more C compilers. For example, TCC is a lot faster than GCC.

The question is the performance optimisations on top.

1990's compilers were also super fast, they only did optimisation for size, speed, constant propagation, and little else.

Zero code motion, loop unroling, code elision, heap via stack replacement, inlining,...

Re: I write games in C (yes, C) (2016)

#202
post #20

I write mostly like I would in C, but use C++ features as needed. It ends up looking similar to Rust if you squint. All these "I write games in C" people complain about C++ features, and then end up reimplementing virtual interfaces manually with struct headers or massive switch statements, just to feel better about themselves. Writing games in C is not harder, you just have to implement modern language features by h…

Of course people do" virtual functions" in C, but I think this is not an argument despite C. I noticed that making virtual in C++ is sooo easy that people start abusing it. This making reading/understanding/debugging code much harder (especially if they mess this up with templates). And here C is a way - it allow but complicates "virtual". So, you will think twice before using it

Most operating systems written in C have it all over the place.

Drivers, and extension points for userspace.

Re: I write games in C (yes, C) (2016)

#203
post #41

Earlier quoted context omitted.

Yeah, you could argue that choosing C is just choosing a particular subset of C++. The main difference from choosing a different subset, e.g. “Google C++” (i.e. writing C++ according to the Google style guide), is that the compiler enforces that you stick to the subset.

C is not a subset of C++, there are some subtle things you can do in C that are not valid C++

It is when compared with C89, also the ISO C++ requires inclusion of ISO C standard library.

The differences are the usual that occur with guest languages, in this case the origin being UNIX and C at Bell Labs, eventually each platform goes its own merry way and compatibility slowly falls apart with newer versions.

In regards to C89 the main differences are struct and unions naming rules, () means void instead of anything goes, ?: precedent rules, implicit casts scenarios are reduced like from void pointers.

Re: I write games in C (yes, C) (2016)

#204
post #41

Earlier quoted context omitted.

Yeah, you could argue that choosing C is just choosing a particular subset of C++. The main difference from choosing a different subset, e.g. “Google C++” (i.e. writing C++ according to the Google style guide), is that the compiler enforces that you stick to the subset.

C's string handling is so abominably terrible that sometimes all people really need is "C with std::string". Oh, and smart pointers too. And hash maps. Vectors too while we're at it. I think that's it.

Yeah, WG14 has had enough time to provide safer alternatives for string and arrays in C, but that isn't a priority, apparently.

Re: I write games in C (yes, C) (2016)

#205
post #144

Earlier quoted context omitted.

You can surely create a std::string-like type in C, call it "newstring", and write functions that accept and return newstrings, and re-implement the whole standard library to work with newstrings, from printf() onwards. But you'll never have the comfort of newstring literals. The nice syntax with quotes is tied to zero-terminated strings. Of course you can litter your code with preprocessor macros, but it's inelegant…

Hacker News seems not to hate antirez's sds https://github.com/antirez/sds https://news.ycombinator.com/item?id=45014911

If only WG14 added something similar to C.

Yes, SDS exists, however vocabulary types are quite relevant for adoption at scale.

Re: I write games in C (yes, C) (2016)

#206
post #201
post #126

Earlier quoted context omitted.

Maybe it is similar for the same compiler (but one should check, I suspect C could still be faster), but then there are much more C compilers. For example, TCC is a lot faster than GCC.

The question is the performance optimisations on top. 1990's compilers were also super fast, they only did optimisation for size, speed, constant propagation, and little else. Zero code motion, loop unroling, code elision, heap via stack replacement, inlining,...

Of course, but gcc with -O0 is still slower and there is no TCC for C++.

Re: I write games in C (yes, C) (2016)

#207

Earlier quoted context omitted.

That's an odd opinion about a language with a lot of class related features. I can only assume you have a very strong definition of OOP.

OOP doesn't mean that your language has a "class" keyword, nor dot notation for calling functions.

I enjoyed the pragmatic historical definition of OOP given in https://www.youtube.com/watch?v=wo84LFzx5nI where essential it can be seen as subtype polymorphism

Re: I write games in C (yes, C) (2016)

#208
post #52

Earlier quoted context omitted.

I feel like, for me, it’s that I am more familiar with writing in C and switching to C++ seems rather difficult. So, sure I am reimplementing features that already exist in anoter language, it just so happens in this case is C++. Why not use python if you want to avoid reimplementing the wheel as much as possible. And sure python is not suited for game development but I just wanted to make a point with it. I think in…

For a solo dev, it's not difficult. C++ is nearly a superset of C. You don't have to adopt all of C++ to start using it and to get immediate benefits from it (for example, unique_ptr, shared_ptr, and vector would all be things that I think any C dev would really appreciate). A reason I can think of to not move to C++ is that it is a vast language and, if you are working on a team, it can be easy for team members ulti…

I learnt C++ on Turbo C++ 1.0 for MS-DOS as teenager, after doing C with Turbo C 2.0.

Being on Borland ecosystem that was followed by several years of Object Pascal (I was already using TP at the time), and C++.

Never got the point of why to keep using C, other than external constraints like school assignments, jobs requirements or lack of compilers.

Re: I write games in C (yes, C) (2016)

#209

"nobody does this" Well, this should be reformulated a bit. Using C is not the norm, but it once was and many people are still using C to write games, myself included.

When people say "nobody .." or "everybody .." they often - maybe even usually - do not literally mean 100.000000% of people. You are an outlier. He is still correct to say "nobody does this".

Re: I write games in C (yes, C) (2016)

#210
post #40

C has very low entry level, providing that you have some knowledge about memory management. When, as a Java developer, I had to quickly deliver some exchange connector using given .h and .so, I chose C, because C++ had too high entry level. If C is a sharp knife, C++ is a rotating pell post full of sharp knives. You can cut yourself even if you think you're safe. But I find string management in C awful and would like…

That's the neat thing about C++. You don't have to use any of it that you don't want to.

That's only really true for solo projects. For example I worked in a company on a C++ SDK for a while and it was written by one of those clever people who has zero taste in software development and thinks you have to use GoF patterns everywhere. The god object was a CRTP inheriting from about 20 templated base classes.

I spent about a year trying to sort out that mess and then quit.

To be clear I would still always pick C++ over C because C makes simple stuff (strings and containers mainly) waaaay more painful than they should be. But I also don't really agree with the "C++ is simple - just don't use the complex bits!" argument.

Anyway it's kind of academic now because 99% of the time Zig is an obviously better choice than C and Rust is an obviously better choice than C++.

Post reply on HN