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

251–260 of 288 posts

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

#251

Post by levodelellis »

petters wrote: post #232
levodelellis wrote: post #138

Earlier quoted context omitted.

tcc is 8x faster, twice as fast isn't doing it justice. As for the header thing, that'd could potentially be true if the compile time was something like 450ms -> 220ms, but why bother saying it when you're only saving a few hundred milliseconds

Going from 220 to 450 ms would be a disaster in my project. It has many thousands of files. Recompilation of almost everything happens from time to time. If those made-up numbers were true, they would be very significant and an argument in favor of keeping the code in C

A 200ms difference is adding or removing 200lines lines of implementation, and spliting it up into a file can make it slower because of include overhead. You completely made up C being twice as fast as C++.

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

#252

Post by jamienicol »

lelanthran wrote: post #194
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…

> Complaining about a language having features you don't want is silly. If your criteria for a good language is "how many features does it have", then sure, C++ wins. OTOH, if you criteria is "How many footguns does the language have" then C++ loses to almost every other mainstream language, which includes C. Sometimes the lack of footguns is a plus.

Surely your criteria should be some combination of the two (plus other factors). C may have fewer footguns than C++, but it still has many, whilst also lacking many useful features

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

#253

Post by uecker »

direwolf20 wrote: post #249
uecker wrote: post #218

Earlier quoted context omitted.

For many string operations such as appending, inserting, overwriting etc. the memory management can be made automatic as well in C, and I think this is the main advantage. Just automatic free at scope end does not work (without extensions).

You can make strings (or bignums or matrices) more convenient than the C default but you can never make them as convenient as ints, while in C++ you can.

Yes, but I do not think this is a good thing. A programming language has to fulfill many requirements, and convenience for the programmer is not the most important.

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

#254

Post by uecker »

direwolf20 wrote: post #243
uecker wrote: post #192

Earlier quoted context omitted.

Ah, the C++ guy who think you need all the features of C++ to be efficient... Many people of people are super productive in C. There is a cost, but this is usually just some initial overhead to identify / write some libraries. In a larger project this initial overhead is irrelevant.

If someone is using a C++ feature it's because they think the feature is better than not using it. std::string lets you treat strings as easily as ints — subject to a run–time cost. You can make libraries that make strings easier to use in C, but you can't make one that makes them as easy as ints.

But it does not have to be "as easy as int" to be able to be productive in C. Almost as easy is sufficient.

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

#255

Post by tialaramex »

teo_zero wrote: post #124
uecker wrote: post #110

Earlier quoted context omitted.

why not std::string?

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…

Because C wants to run on bare metal, an allocating type like C++ std::string (or Rust's String) isn't affordable for what you mean here.

I think you want the string slice reference type, what C++ called std::string_view and Rust calls &str. This type is just two facts about some text, where it is in memory and how long it is (or equivalently where it ends, storing the length is often in practice slightly faster in real machines so if you're making a new one do that)

In C++ this is maybe non-obvious because it took until 2020 for C++ to get this type - WG21 are crazy, but this is the type you actually want as a fundamental, not an allocating type like std::string.

Alternatively, if you're not yet ready to accept that all text should use UTF-8 encoding, -- and maybe C isn't ready for that yet - you don't want this type you just want byte slice references, Rust's &[u8] or C++ std::span

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

#256

Post by 1718627440 »

nayuki wrote: post #247
guerrilla wrote: post #97

Earlier quoted context omitted.

> I agree on C++ being the worst of both worlds for many people. You get abstraction, but also an enormous semantic surface area and footguns everywhere. Not only that, but who even knows C++? It keeps changing. Every few years "standard practice" is completely different. Such a waste of energy. > Java is interesting because the core language is indeed small and boring in a good way, much closer to C than people admi…

> no-unsigned-integers [...] still bothers me I like the lack of unsigned integers in Java. It simplifies the language while only removing a tiny bit of functionality. You can emulate almost all unsigned math using signed operations, whether you use a wider bit width or even the same bit width. The only really tricky operations are unsigned division and unsigned parseInt()/toString(), which Java 8 added to smooth thi…

The reason for using unsigned is not that some operations need it, it is so to declare a variable that can't be negative. If you don't have that, then you must check for a negative number in every single interface.

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

#257

Post by 9rx »

direwolf20 wrote: post #248
9rx wrote: post #219

Earlier quoted context omitted.

It doesn't need to link. That is the complete program. Are you suggesting I need to pass a flag to the C++ compiler to disable the linker? How do I do that?

Oh, I see what you meant now. I don't think it works: ./test: line 1: hlt: command not found ./test: line 2: jmp: command not found Do you get a dopamine hit out of this?

No, that is right, assembly doesn't work in what looks like the output of a Unix shell. Assembly is intended to be input to an assembler. Easy mistake to make, I suppose.

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

#258

Post by patrick451 »

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…

At least you can read the switch statement. One of the worst features of c++ is all of the code that gets generated for you automatically.

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

#259

Post by pjmlp »

uecker wrote: post #235
pjmlp wrote: post #228

Earlier quoted context omitted.

There are other C++ compilers to benchmark against, using the same common C subset for comparison, though.

Is there still any non-LLVM C++ compiler left besides GCC? LLVM is not exactly known for its speed.

Many embedded vendors still haven't made the jump, and Microsoft.
Post reply on HN