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

How to write better game libraries

handmade.network

Post reply on HN
Print view View original

51–60 of 129 posts

Re: How to write better game libraries

#51

Post by pjmlp »

kd5bjo wrote: post #26
pjmlp wrote: post #21

Earlier quoted context omitted.

Other than UNIX like kernels and tiny PIC micro-controllers no one else should still be programming in straight C in 21st century.

That may be so, but the central thesis of the article is that C is the still the appropriate language in which to write libraries for interoperation. If you believe otherwise, I suspect that a rebuttal of the author’s arguments in favor of C would be well-received as a top-level comment here— there seem to be a lot of people that agree with you, but nobody has yet stated why they hold that opinion.

Sure, first of all there is no such thing as C ABI, only OS ABI.

C ABI happens to be the mixed up with OS ABI, on OS written in C like UNIX clones, on mainframes, and other competing OSes that isn't the case, because they use other systems languages on their stack, or even some kind of bytecode based interoperability format.

However since the context here is game libraries, C ABI == OS ABI pretty much applies everywhere (except WebAssembly or Android JNI) and lets leave at there.

Since C++98, writing a library in C++, even if exposing it as extern "C", provides the following benefits for the quality of code implementation:

- less implicit conversions

- use of reference types instead of pointers for memory accesses we can be sure are never allowed to be null

- use of namespaces instead of Assembly style programming of having to come up with prefixes for code organization

- bounds checking for strings, vectors and other related data structures provided one uses the library types. They can even be left turned on for release mode, if the profiler shows there is no visible impact on hot paths

- use of RAII to manage library internal state and reduce leak occurrences

- ISO C++ working group is actually striving for reducing the amount of UB from its 200+ use cases, unlike ISO C group

- strong typed enums introduced in C++11 don't have implicit conversions and must map to their underlying types

- type safe compile time code execution, specially helpful in games, used for stuff like generating trigonometry tables

- templates as replacement for pre-processor magic that eventually goes subtly wrong when the #include order gets misplaced or too few parenthesis are used

If this still sounds absurd, well all major C compilers are now implemented in C++, Microsoft rewrote their C standard library in C++ with extern "C" entry points, Android NDK is actually implemented in a mix of C++ and Java (via JNI) also using extern "C" calls.

Re: How to write better game libraries

#52

Post by jstimpfle »

pjmlp wrote: post #47
jstimpfle wrote: post #25

Earlier quoted context omitted.

If people choose to and it gives them joy, and they are productive and even learn valuable things, why not let them be?

Because if someone else happens to use that library, it might blow up on their face, e.g. WhatsApp dependency on android-gif-drawable. https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-1193...

Are you looking for a safe way to use your computer? Turn it off.

Other than that, I'm not surprised the file in question is C. Even ignoring the fact that it was you to get the link. And even ignoring that it's about a security problem...

Other than that, from a user perspective, software written in C is among the most reliable software I'm using. I'm looking at Linux, vim, xterm and so much of the infrastructure that I don't even know by name.

Some people value "security" more than they value the beauty of a nice, a maintainable, or a practical program. That's ok as far as I'm concerned...

Re: How to write better game libraries

#53

Post by comex »

Const-me wrote: post #38
kd5bjo wrote: post #30

Earlier quoted context omitted.

Especially with this expanded commentary, you do show some advantages of C++ over C, but you have only addressed the advice for how to proceed once you’ve chosen C and not the author’s reasons for preferring C to C++ (or any other language): — Every language out there has a way to call into C — If your code is slower than C, someone will rewrite it in C. — If your library is written in C it means it can be used on an…

> If your code is slower than C, someone will rewrite it in C. When used correctly, C++ is not slower than C. Sometimes faster, a classic example is C qsort versus std::sort. > If your library is written in C it means it can be used on any OS, console or mobile device and even on the web. C++ is good in that regard. I know only 1 mainstream platform where C++ adds significant friction compared to C, that’s iOS, becau…

> I know only 1 mainstream platform where C++ adds significant friction compared to C, that’s iOS, because their objective C is a superset of C.

Apple’s compiler supports overlaying Objective-C features on top of C++ instead of C; it’s called Objective-C++.

Re: How to write better game libraries

#54

Post by Const-me »

jstimpfle wrote: post #48
Const-me wrote: post #45

Earlier quoted context omitted.

> what's the practical difference between NS::foo() and NS_foo() with regards to preventing name collisions. They both do the job. There’re 2 practical differences. 1. You can write `using namespace` inside functions or the whole .cpp files. This often makes the consuming code more readable. 2. Sometimes you want to replace implementations. With prefixes it gonna be massive changes likely to introduce new bugs. With…

Code completion works very well with plain identifiers. No need for namespaces. > replace `using std::vector` with `using eastl::vector` and you’re done. The pipe dream of reusability.. If I ever happen to be in a situation where that will work, I'll happily use a text replace to change my identifiers. Or just link a different library if it has the same names.

> Code completion works very well with plain identifiers.

It doesn’t on my PC.

I’ve copy-pasted C enum from your example, when I type FPG there’s no way to auto-complete just the FPGAPARAM_ part, to be able to then press F to get FPGAPARAM_FOO. Using VC2017 here, with latest Visual Assist.

Which C++ IDE are you using?

> The pipe dream of reusability.

Did it more than once.

Here’s one open source project where I’ve replaced most parts of the C++ standard library with EASTL: https://github.com/Const-me/vis_avs_dx

Here’s my header-only C++ library which allows users to switch between 16-bytes/32-bytes wide SIMD by using different C++ namespace, either Intrinsics::Sse or Intrinsics::Avx: https://github.com/Const-me/IntelIntrinsics/

Re: How to write better game libraries

#55

Post by js8 »

fortran90 wrote: post #6

Since this article lays so much emphasis on C, I have an honest question to everyone. What is a good way for a beginner to learn C in the current time? The minefield of undefined behavior is really overwhelming to a beginner. Are there any good resources that teach C the right way with good advice and best practices to navigate the UB minefield?

If you already know it a bit, I think https://modernc.gforge.inria.fr/ is pretty good.

Re: How to write better game libraries

#56

Post by Const-me »

comex wrote: post #53
Const-me wrote: post #38

Earlier quoted context omitted.

> If your code is slower than C, someone will rewrite it in C. When used correctly, C++ is not slower than C. Sometimes faster, a classic example is C qsort versus std::sort. > If your library is written in C it means it can be used on any OS, console or mobile device and even on the web. C++ is good in that regard. I know only 1 mainstream platform where C++ adds significant friction compared to C, that’s iOS, becau…

> I know only 1 mainstream platform where C++ adds significant friction compared to C, that’s iOS, because their objective C is a superset of C. Apple’s compiler supports overlaying Objective-C features on top of C++ instead of C; it’s called Objective-C++.

I once forked a C library, porting some parts to C++ in the process: https://github.com/Const-me/nanovg/ I’ve retained original C API, only used C++ in the implementation.

Then I’ve got an e-mail from a developer who asked a few things how to back port my changes to C. I answered their questions, but I was curious why. They replied it’s because Objective C and iOS. Personally, I haven’t been developing for iOS for several years, but I don’t think people would do such things for lulz.

Re: How to write better game libraries

#57

Post by eru »

je42 wrote: post #43
LessDmesg wrote: post #28

Earlier quoted context omitted.

> modern C++ > pleasant Nice joke. Hour-long compilations, type-unsafe templates with unreadable errors, and circular references are considered pleasant now?

- reasonable organized code doesn't take hours. even template heavy code is quite fast these days - templates are type safe. it is just the error messages are not helpful a lot of times. C++20's concepts should help - circular references. that's a thing in C as well. as soon as you need interact with your libraries user to allocate/deallocate resources. C++ has a large surface to interact with. Yes you can shot yours…

Templates are duck typing at C++ compile time (which is their runtime). Yes, concepts should help.

'Modules via copy-and-paste' (= #include) is what I would hurl at C++ these days. Though they are working on that as well, I heard. Though https://vector-of-bool.github.io/2019/01/27/modules-doa.html doesn't sound hopeful.

Re: How to write better game libraries

#58

Post by astrobe_ »

huhtenberg wrote: post #42
astrobe_ wrote: post #17

Make is a much the lingua franca of build systems as C is for programming, so there's no reason not to provide a (simple) makefile. The alternative they suggest is worse anyway.

Windows is the reason make is not a good choice. Visual Studio is a de-facto standard for Windows development and it's not exactly makefile-oriented. The lowest common denominator for build instructions that works everywhere is literally "set your include paths like so and compile these sources".

How strange. I have tinkered with a couple of FOSS games of Windows and none of them required VS (not to mention another couple of other non-game projects). Maybe that's because they often are multi-platform projects so Make is the best choice at the global level for them?

> The lowest common denominator for build instructions that works everywhere is literally "set your include paths like so and compile these sources".

Yes, but that's quite inconvenient and error-prone ; a typo in a -D flag is very likely to not compile what you wanted.

Make is not a multi-megabyte program with a frack tonne of dependencies. Having your users to install it in order to build your project is far from being completely outrageous (unless for coughmicrosoftcough cults that consider the command-line is evil).

Re: How to write better game libraries

#59

Post by starsinspace »

pjmlp wrote: post #21
kd5bjo wrote: post #16

Earlier quoted context omitted.

C++ features don’t help when you’re programming in straight C, as the article advises.

Other than UNIX like kernels and tiny PIC micro-controllers no one else should still be programming in straight C in 21st century.

I agree that "straight C" is not the best choice anymore... but C++ isn't great either. It inherits most of C's weaknesses and for libraries, it makes it very difficult to use the code from languages other than C++. By making a library in C++ you are basically limiting it to being used only in C++ projects. (Yes, wrapper generators for C++-to-whatever exist, but my experience with using e.g. Qt from other languages has always been pretty terrible).

Even in 2019, the C ABI is the one universally agreed-upon cross-language ABI for languages compiled to native code.

Re: How to write better game libraries

#60

Post by pjmlp »

comex wrote: post #53
Const-me wrote: post #38

Earlier quoted context omitted.

> If your code is slower than C, someone will rewrite it in C. When used correctly, C++ is not slower than C. Sometimes faster, a classic example is C qsort versus std::sort. > If your library is written in C it means it can be used on any OS, console or mobile device and even on the web. C++ is good in that regard. I know only 1 mainstream platform where C++ adds significant friction compared to C, that’s iOS, becau…

> I know only 1 mainstream platform where C++ adds significant friction compared to C, that’s iOS, because their objective C is a superset of C. Apple’s compiler supports overlaying Objective-C features on top of C++ instead of C; it’s called Objective-C++.

Except that only old timers, have the Objective-C++ documentation available, because Apple has removed it from their web site.
Post reply on HN