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

101–110 of 129 posts

Re: How to write better game libraries

#101

Post by Const-me »

abcd_f wrote: post #97
Const-me wrote: post #90

Earlier quoted context omitted.

It’s easy enough to correctly use a small API in a small program. It doesn’t matter at all for short-living apps which clean up their resources by exiting the process. There’re also other programs in wide use, which need to reliably work for hours, sometimes weeks. Some of them have huge amount of code they built from, written by many people over many years. Combine that with large enough APIs (some peripheral device…

It's easy enough to implement correct API usage semantics in a program of any size. If you need to rely on RAII in order not to screw things up, then it's an issue with the coding style or the application design. That's what needs fixing. Not the language choice. You got it backwards.

It’s a hard problem, and language + runtime support helps. That’s why C++ has RAII, C# has IDisposable / using, Java has try-with, python has enter / exit / with, golang has defer, and so on. The only reason C has nothing comparable, it’s almost 50 years old now.

The problem is only tangentially related to API semantics. The problem is mutating state. The state is not necessarily managed by an API, for instance CPU registers aren’t, you modify them directly. Same with other global state like I/O formatting options and locales, these things are just global variables.

Re: How to write better game libraries

#102

Post by novok »

rehasu wrote: post #81

The problem for game libraries in general is that game dev lives in c++ world and c++ is awful for libraries. Most c++ devs I know would rather start writing a program by defining string than by learning to handle proper library management tooling. I'm not an expert so I'm not sure if it's just a culture thing or if there are inherent features in the language that make library usage hard, but yeah. That's that.

I wish the C++ world would adopt bazel eventually as their standard tooling base.

Re: How to write better game libraries

#103

Post by erikbye »

pjmlp wrote: post #14
saagarjha wrote: post #9

I don't see it mentioned, but it's important to note that you don't have to write your library in the same language that you expose to your users. You can write everything in C++/Rust/Python and expose something compatible with the C ABI and people will be able to use it (provided they have your toolchain…)

Fully agree with you. Anyone providing a library written in pure C, better be serious about security and prove that they have taken all the required steps to handle memory corruption and UB exploits. We really need more liability on software development.

Do note where this article resides. Casey Muratori (of Handmade Hero, a game dev tutorial project) is a self-proclaimed anything-not-C hater. A community has formed around his project, and has, of course, adopted his hard-line stance.

Re: How to write better game libraries

#104

Post by drjeats »

Nice article :)

Might be worth touching on error callbacks/logging as an error handling strategy.

Sometimes an error is not recoverable in the sense that the calling code can't really do anything about it, but the library should attempt to make progress anyway instead of halting the entire program.

By allowing users to specify an error callback, this means they can log errors, capture stack traces, assert, or whatever.

This isn't that helpful for smaller libraries with smaller-scoped processes, but if it's something like a renderer or interactive audio lib, those often just need to be given a bunch of frame time to do work with the complex input you've prepped and fed to it, and trying to propagate error codes up out of that simulation step would both contort the inner code and not be as helpful as an error callback.

With an error callback you can assert, set breakpoints, or do whatever. But more importantly, by default you can have it just log so when you inevitably in a bug it doesn't prevent everyone else from getting work done while it keeps asserting until you fix your shit.

This will be a less common need than the other standard error reporting mechanisms, but is important to get right if your library has these complex internal preconditions that you want to make visible to the client when violated.

Re: How to write better game libraries

#105

Post by pjmlp »

huhtenberg wrote: post #79
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.

Reading through your comments the only take-away appears to be that you just really don't like C for whatever reason. C is a perfectly fine language for tasks of all kinds. The fact that it expects programmers to take greater care when using it is not a reason enough to dismiss it as a general-purpose language. Not everyone needs (or wants) to ride a tricycle wearing knee pads and a helmet to get from A to B.

Ah the old straight jacket argument against computer security, never gets old.

The reason is very simple, the billions of wasted money fixing security exploits caused by industry's adoption of C.

Morris worm is more than 30 years old, and the old ways can still be used to attack modern systems that people insist in writing using C.

https://msrc-blog.microsoft.com/2019/06/14/prevent-the-impac...

https://support.apple.com/en-us/HT210348

https://msrc-blog.microsoft.com/2019/07/16/a-proactive-appro...

https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Pr...

https://security.googleblog.com/2019/08/adopting-arm-memory-...

Re: How to write better game libraries

#106

Post by pjmlp »

jstimpfle wrote: post #93
pjmlp wrote: post #61

Earlier quoted context omitted.

The guys attending the Linux Kernel Security Summit seem to think otherwise, plenty of stuff there to entertain yourself.

Sure there is. But never be blinded, Linux is very performant and rock solid from an end user's viewpoint. Sometimes it helps putting things into perspective.

Indeed,

https://msrc-blog.microsoft.com/2019/06/14/prevent-the-impac...

https://security.googleblog.com/2019/08/adopting-arm-memory-...

https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Pr...

Seatbelts and helmets are also a nuisance, maybe we should get rid of them, that is my perspective.

Re: How to write better game libraries

#107

Post by pjmlp »

erikbye wrote: post #103
pjmlp wrote: post #14

Earlier quoted context omitted.

Fully agree with you. Anyone providing a library written in pure C, better be serious about security and prove that they have taken all the required steps to handle memory corruption and UB exploits. We really need more liability on software development.

Do note where this article resides. Casey Muratori (of Handmade Hero, a game dev tutorial project) is a self-proclaimed anything-not-C hater. A community has formed around his project, and has, of course, adopted his hard-line stance.

Interesting, thanks for the hint.

Re: How to write better game libraries

#108

Post by rumanator »

novok wrote: post #102
rehasu wrote: post #81

The problem for game libraries in general is that game dev lives in c++ world and c++ is awful for libraries. Most c++ devs I know would rather start writing a program by defining string than by learning to handle proper library management tooling. I'm not an expert so I'm not sure if it's just a culture thing or if there are inherent features in the language that make library usage hard, but yeah. That's that.

I wish the C++ world would adopt bazel eventually as their standard tooling base.

> I wish the C++ world would adopt bazel

Why do you believe picking a specific build system is relevant wrt libraries, particularly a build system whose main selling point is build speed.

Re: How to write better game libraries

#109

Post by anon4242 »

FreeFull wrote: post #78
ginko wrote: post #49

Earlier quoted context omitted.

IMO the ideal way to get your library used is to generate a single .h and .c file.

Some libraries don't even ship a .c file, all the code is in the header

The downside of that is that all code is in the header. As in you will compile all the library code whenever you include the header. As third-party library code is something you probably seldom change yourself, you don't want your build to spend time building it all the time.

Sure some of those libs may have some define you need to set in one of your .c files so the implementation will go there but then whenever you change that file it will result in a recompile of the third-party lib. So then you go and create a separate .c file just for the lib and we're back to why the lib author didn't do that in the first place?

No, I think what sqlite does is pretty neat. If you're doing development in the sqlite code-base you have lots of files (so you can manage it) but if you just want to use sqlite, you have the amalgamation which is one .c and one .h.

Re: How to write better game libraries

#110

Post by rumanator »

LessDmesg wrote: post #28
jandeboevrie wrote: post #8

This is bad advice on the c++ part. If you don't use RAII, then you could've just not done the c++ lib (and have just a c lib). Exceptions, raii and smart pointers are what makes modern c++ so pleasant, next to templates.

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

> Hour-long compilations,

If your project takes hours to compile them you only have yourself to blame.

> type-unsafe templates

There is no such thing.

> with unreadable errors,

That's an implementation issue, not a language issue.

> and circular references

If you write buggy code then you only have yourself to blame.

Post reply on HN