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

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

jonathanwhiting.com

Post reply on HN
Print view View original

181–190 of 288 posts

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

#181

Post by Panzerschrek »

tialaramex wrote: post #167
torlok wrote: 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…

> then end up reimplementing virtual interfaces manually C++ dynamic dispatch (your "virtual interfaces") is achieved by welding a vtable onto every type and providing a pointer to that vtable for instances of the type. If in 90% of your code you deal with specific types like Goose or Swan or Duck or Seagull, and only 10% needs to work with the broad Bird category well, too bad, every Goose, Swan, Duck and Seagull ca…

> by welding a vtable onto every type

It's not true. Virtual methods table is present only for classes with at least one virtual method. Learn C++ properly before doing such claims.

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

#182

Post by smallstepforman »

direwolf20 wrote: post #156
uecker wrote: post #3

Earlier quoted context omitted.

Why do you think working with a group of people on a C codebase introduces pain unlike other languages? Working with a group of people always causes pain, but I found the pain much less severe for C than for C++.

C relies on the programmer to understand the lifetime of every object in the program, which is global structure. When the programmer is multiple people, it's easy to get out of sync. unique_ptr from C++ solves 90% of this.

Ever use a leak detector? Even my graphics engines (with shared resources) uses a leak detector in debug mode. The monent you forget to release a resource, assertion at program termination.

Leaks are trapped with tooling, and all you need is one dev in the team to be diligant to run valgrind or visual leak detector or similar.

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

#183

Post by smallstepforman »

heliumtera wrote: post #13
Keyframe wrote: post #2

In my core I'm the same. C is my language and served me well for decades. There's nothing inherently major wrong with it until you reach one of the two (or both). Working in a group of people on a C codebase tends to introduce pain on multiple levels unlike some other languages (yes, including C++). The other is that anything takes a long-ass time to do compared to modern alternatives, which might also be an issue if…

>Working in a group of people on a C codebase tends to introduce pain on multiple levels unlike some other languages linux attracted 2,134 developers in 2025 that kinda weakens your argument a little bit

If Linus started his OS project in 2026, he might have chosen Zig instead of C.

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

#184

Post by throwaway2046 »

direwolf20 wrote: post #159
9rx wrote: post #149

Earlier quoted context omitted.

Nothing about a dopamine hit out of it, no. Something about _main being an undefined symbol. Are you familiar with that error message?

How did your equivalent assembly program without a definition of _main to? You're doing that thing. I think it's called "trolling". It goes like "hurr durr, they said take one, but they wouldn't let me take one plate" or "hurr durr, I filled my gas tank with nitrogen, which is a gas, but my car doesn't go" or "hurr durr, they said C++ features are all optional, but I don't want to use letters, how can I write C++ wit…

> that guy asked Stack Overflow how to make gcc compile his .png

Do you have a link to this? All the search results I'm getting are related to libpng.

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

#185

Post by nurettin »

smallstepforman wrote: post #180

Noble quest, but without operator overloading when dealing with Matrix*Vector you end up with an unreadable mess for physics, skeletal animation etc. There is a reason professional game dev is still 90% C++. (Funny enough, amateur gamedev is C# these days, students use what they learn at uni).

Funny enough, amateur gamedev using C# is a billion USD industry.

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

#186

Post by csb6 »

ddtaylor wrote: post #104

I need RAII and refuse to debug ugly macros as a workaround. The STL isn't perfect but it's a good guiding principle.

Yes, having built-in generic containers and algorithms is the part that keeps me favoring C++. Bespoke versions of these can always be written in C (and work fine) but C++ makes it much easier and saves time. Lambdas and function objects are also useful.

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

#187

Post by Suppafly »

torlok wrote: 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…

>C is not harder, you just have to implement modern language features by hand

That's definitely harder.

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

#188

Post by uecker »

direwolf20 wrote: post #146
uecker wrote: post #122

Earlier quoted context omitted.

Sure, but you can have a similar string abstraction in C. What would you miss? The overloaded operators?

Automatic memory accounting — construct/copy/destruct. You can't abstract these in C. You always have to call i_copied_the_string(&string) after copying the string and you always have to call the_string_is_out_of_scope_now(&string) just before it goes out of scope

This seems orthogonal to std::string. People who pick C do not want automatic memory management, but might want better strings.

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

#189

Post by uecker »

smallstepforman wrote: post #182
direwolf20 wrote: post #156

Earlier quoted context omitted.

C relies on the programmer to understand the lifetime of every object in the program, which is global structure. When the programmer is multiple people, it's easy to get out of sync. unique_ptr from C++ solves 90% of this.

Ever use a leak detector? Even my graphics engines (with shared resources) uses a leak detector in debug mode. The monent you forget to release a resource, assertion at program termination. Leaks are trapped with tooling, and all you need is one dev in the team to be diligant to run valgrind or visual leak detector or similar.

We run valgrind and asan as part of the CI, so it is checked before every merge and no developer has to be particularly diligent. But it is also not something that triggers a lot.

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

#190

Post by uecker »

Keyframe wrote: post #62
uecker wrote: post #3

Earlier quoted context omitted.

Why do you think working with a group of people on a C codebase introduces pain unlike other languages? Working with a group of people always causes pain, but I found the pain much less severe for C than for C++.

Your question also hides an answer. You don't often get to chose a group of people you work with, and unlike projects that self-attract and self-distill ideal profile (like linux mentioned in sister comment), you're left with people usually not used to ye olde C idioms. With C++ it's a bit easier since it is more widespread and supports some of the idioms people get used through schools and other projects. Of course,…

I would argue that is is much harder to find a group of C++ programmers who write a coherent style of C++. In C there is not nearly as much to decide. Note also that I am speaking from experience with both.
Post reply on HN