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

91–100 of 129 posts

Re: How to write better game libraries

#91

Post by snovv_crash »

EliRivers wrote: post #73
a_t48 wrote: post #12

Earlier quoted context omitted.

FWIW I’ve never been at a job that allows exceptions...but smart pointers and RAII are great.

On the other side of the coin, I don't think I've ever had a job in which anyone would have ever considered banning exceptions (although I have worked at some where people did know that some other companies did ban them). The world of programming is a very broad church indeed.

Often bare-metal embedded toolchains don't support stack unwinding. I've even worked on an embedded linux where the toolchain didn't support stack unwinding. It made porting certain code to the platform interesting, to say the least.

Re: How to write better game libraries

#92

Post by Profan »

huhtenberg wrote: post #35
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?

> the UB minefield While UB quirks exist, they are WAY off the beaten path and it takes an effort to run into them. Doubly so if you are just starting with the language. Just treat C as a thin convenient layer over the hardware that expects you to think and act responsibly in exchange for this nearly raw access.

In C (and C++) something as simple as forgetting to initialize a variable lands you in UB-land already, nearly every person I knew when I was learning myself (and still now) ran into these things _very quickly_.

Not to mention compilers make fun-times out of this by sometimes zeroing memory in debug and then not doing so for release builds (Hi MSVC!)..

The "thin layer over hardware" idea is a thing of the past as soon as optimizations come into the picture, and even then.

Re: How to write better game libraries

#93

Post by jstimpfle »

pjmlp wrote: post #61
jstimpfle wrote: post #52

Earlier quoted context omitted.

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

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.

Re: How to write better game libraries

#94

Post by grawprog »

Honestly, for me all I would like is the ability to include/import one or more files as needed, helpfully separated by basic functionality, without needing to include the entire library, have a bare minimum of dependencies, hopefully, module independent, the ability to build painlessly for different platforms with a minimum of code changes and a painless build process for the library itself, ideally one I can include in my own build process without a lot of effort.

I've used some libraries that do some of these things, but I can't think of any that does all of them.

Re: How to write better game libraries

#95

Post by jstimpfle »

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

Earlier quoted context omitted.

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

I use VS at work, and I'm very happy with its code completions (except that the auto-popup behaviour is so unreliable or at least unintuitive. I'm sure there is an option to turn that off). I'm not aware of a way to complete to the largest prefix that is common to all completions, although something like that would be rather easy implement, too.

Re: How to write better game libraries

#96

Post by overgard »

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.

It’s pretty inherent to the tooling around the language. Basically because theres a lack of “standard” tooling, so you either go lowest-common-denominator (header only), or you have to fuss with very gross build systems that have weird quirks on different platforms.

C is easier in this regard just because the language evolves so slowly that even though the build and library systems are bad, theyre a known bad that people can work around. No such luck with C++, where its bad and ever changing.

Re: How to write better game libraries

#97

Post by abcd_f »

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

Earlier quoted context omitted.

> The * hard part * is making sure you release stuff every time, exactly once. Oy vey... you can't be serious. That's rudimentary basics of using any API.

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.

Re: How to write better game libraries

#98

Post by a_t48 »

EliRivers wrote: post #73
a_t48 wrote: post #12

Earlier quoted context omitted.

FWIW I’ve never been at a job that allows exceptions...but smart pointers and RAII are great.

On the other side of the coin, I don't think I've ever had a job in which anyone would have ever considered banning exceptions (although I have worked at some where people did know that some other companies did ban them). The world of programming is a very broad church indeed.

What kinds of work were you doing that allowed exceptions?
Post reply on HN