Live data from Hacker News

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

jonathanwhiting.com

271–280 of 288 posts

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

#271
post #254

Earlier quoted context omitted.

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.

It's not almost.

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

#272
post #253

Earlier quoted context omitted.

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.

Empirically it is. All the most used languages are the most convenient ones.

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

#273

Earlier quoted context omitted.

I’ve seen this play out a lot. People say they “write games in C” and then quietly rebuild half of C++ anyway with vtables in structs or giant switch statements, just without the compiler helping. That’s fine if it makes you happier, but it’s not obviously simpler or safer. Also, C++ compile times are mostly a self-inflicted wound via templates and metaprogramming, not some inherent tax you pay for having virtual fun…

It's important that you do these things yourself before you utilise the compiler to do them for you, so you have real understanding.

[deleted]

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

#274
post #257

Earlier quoted context omitted.

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.

But I don't want to use an assembler.

Well, fine. Doesn't build. Says somehow about undefined symbol _main

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

#275
post #257

Earlier quoted context omitted.

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.

But I don't want to use an assembler. Well, fine. Doesn't build. Says somehow about undefined symbol _main

Funny, I haven't told you anything about the architecture yet. But as you don't want to use the tools anyway and it is only a three byte program for the target machine, the good news is that it can quite easily be assembled by hand. Now, back to the C++ problem, any idea what the next step to get us past the issue?

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

#276

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

You should try writing something serious in C just for the hell of it. And without RAII-like macros. Write all your allocs and frees.

I very much have. I specifically like to craft ISAs for genetic algorithms over the last two decades. It's not work I publish because I never feel like it matters, although I regret that often. I very much enjoy writing C for this purpose in many ways and I actually enjoy some of the allowances that fit very well to writing an ISA where every bit of the instruction must map to valid behavior and nothing can be an invalid instruction.

It's an ongoing struggle!

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

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

Your example is disingenuous. What you are stating is the obvious trivial way of doing something when your objective is actually quite different.

You can get exactly what you are asking for in C++ using techniques of static polymorphism and CRTP pattern (https://en.wikipedia.org/wiki/Curiously_recurring_template_p... and https://en.wikipedia.org/wiki/Barton%E2%80%93Nackman_trick) along with traits and dynamic dispatch (if needed).

For great examples of the above, see the classic Scientific and Engineering C++: An Introduction with Advanced Techniques and Examples by Barton & Nackman (1994).

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

#279

Earlier quoted context omitted.

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

Your example is disingenuous. What you are stating is the obvious trivial way of doing something when your objective is actually quite different. You can get exactly what you are asking for in C++ using techniques of static polymorphism and CRTP pattern ( https://en.wikipedia.org/wiki/Curiously_recurring_template_p... and https://en.wikipedia.org/wiki/Barton%E2%80%93Nackman_trick ) along with traits and dynamic dispa…

What you're describing is needing to use specific verbose patterns to opt out of the defaults that do more complex things under the hood, whereas they're describing how C and Rust do not do those things by default and instead let you opt into them. It's not disingenuous to point that out.

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

#280
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++ reimplements a lot of the things we do in C with function pointers, while hiding what's actually happening behind topheavy syntax that implies a 1990s object oriented paradigm that's dead now.

What modern GUI in mainstream OSes isn't using OOP?

Have you bothered to look how GCC and clang are implemented?

Post reply on HN