How to write better game libraries • Hacker News Board

Re: How to write better game libraries

#21

Post by pjmlp » Sun, Dec 08, 2019, 9:41 AM UTC

kd5bjo wrote: post #16

Const-me wrote: post #15

Some of these recommendations are awesome, others aren’t good, IMO. > Always prefix your names to avoid name collisions Solved by C++ namespaces. > Use header guards instead of #pragma once. #pragma once is supported by all mayor compilers, header guards can introduce bugs, also #pragma once builds measurably faster: https://github.com/electronicarts/EASTL/blob/3.15.00/include... > Expose constants to the user using…

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.

Re: How to write better game libraries

#22

Post by seba_dos1 » Sun, Dec 08, 2019, 9:44 AM UTC

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

>provided they have your toolchain…

That's important here. Some of my projects have something around 10 cross-compilation toolchains for various platforms. If a library is written in standard C99, adding it to the project is a breeze. Otherwise...

Re: How to write better game libraries

#23

Post by shmerl » Sun, Dec 08, 2019, 9:46 AM UTC

> Write the library in Standard C99

Why not write it in Rust, and provide C99 bindings? Using stock C for the actual library doesn't sound like a good idea to me, when today there are better alternatives.

And for sure avoid using Metal lock-in directly. Use Vulkan, which Apple should have supported from the beginning. For lock-in targets, there are translation options from Vulkan.

Re: How to write better game libraries

#24

Post by Const-me » Sun, Dec 08, 2019, 9:46 AM UTC

sharpneli wrote: post #18

Const-me wrote: post #15

Some of these recommendations are awesome, others aren’t good, IMO. > Always prefix your names to avoid name collisions Solved by C++ namespaces. > Use header guards instead of #pragma once. #pragma once is supported by all mayor compilers, header guards can introduce bugs, also #pragma once builds measurably faster: https://github.com/electronicarts/EASTL/blob/3.15.00/include... > Expose constants to the user using…

And then there is things like windows.h defining max which breaks std::max. Sure that one has another define which prevents it but not all libraries have. C++ defines don’t respect namespaces so you are pretty much screwed in anycase.

The OP’s advice to avoid macros in the library’s API is a good one. Please read my previous comments, it begins with “Some of these recommendations are awesome”.

BTW, you can disable these windows.h macros by defining NOMINMAX. I usually do, because I prefer min/max from ; in some edge cases std::min / std::max can be twice as fast because compiler guarantees to compute arguments exactly once.

Re: How to write better game libraries

#25

Post by jstimpfle » Sun, Dec 08, 2019, 9:49 AM UTC

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.

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

Re: How to write better game libraries

#26

Post by kd5bjo » Sun, Dec 08, 2019, 9:53 AM UTC

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.

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.

Re: How to write better game libraries

#27

Post by Const-me » Sun, Dec 08, 2019, 10:03 AM UTC

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.

> but nobody has yet stated why they hold hat opinion.

I did, in my first comment.

C++ namespaces lead to much more readable code, compared to these prefixed names.

C++/11 scoped enums eliminate a class of bugs: when you have many different constants on the API surface, multiple functions accepting them, and erroneously use the constant of a wrong function. Example:

    enum Lod { Low, High };
    enum SomethingElse { Other };
    void setLoD( enum Lod v );
    void bug()
    {
        setLoD( Other );
    }

Re: How to write better game libraries

#28

Post by LessDmesg » Sun, Dec 08, 2019, 10:09 AM UTC

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?

Re: How to write better game libraries

#29

Post by rootlocus » Sun, Dec 08, 2019, 10:15 AM UTC

edem wrote: post #2

Please add (C) to the title of the article. In this form, it is misleading because most of the advice only applies to C.

The (games) in the title pretty much limits the article to C / C++

Re: How to write better game libraries

#30

Post by kd5bjo » Sun, Dec 08, 2019, 10:17 AM UTC

Const-me wrote: post #27

kd5bjo wrote: post #26

Earlier quoted context omitted.

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.

> but nobody has yet stated why they hold hat opinion. I did, in my first comment. C++ namespaces lead to much more readable code, compared to these prefixed names. C++/11 scoped enums eliminate a class of bugs: when you have many different constants on the API surface, multiple functions accepting them, and erroneously use the constant of a wrong function. Example: enum Lod { Low, High }; enum SomethingElse { Other…

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 any OS, console or mobile device and even on the web.

— Not everyone wants to use C++ (some prefer C).

— It is easier in general for a C++ user to use a C library than it is for a C user to use a C++ library.

— C++ is not as easy to write wrappers for in other languages.

— Unless you limit which C++ features you use (to the point where you are pretty much left with C) a lot of people won’t be able to use your library.

PS. If your original comment had been phrased the way you put it here I might have made the same comment, but I would not have downvoted it. Here, you’re at least providing some supporting evidence for your assertions which makes it a much more valuable contribution to the conversation.