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

111–120 of 129 posts

Re: How to write better game libraries

#111

Post by matheusmoreira »

LucaSas wrote: post #89
flohofwoe wrote: post #41

As a warning: While C99 is a really nice language - especially over C89 - please note that the Visual Studio C compiler still does not support the full C99 specification, and it is not possible at all to compile C99 as C++ code (which sometimes is useful). I usually recommend to write library-level code in the "subset of C99 which compiles both in C and C++ mode on GCC, clang and MSVC". This is basically a version of…

Thanks for the comment, I might steal your "subset of C99 which compiles both in C and C++ mode on GCC, clang and MSVC" quote and put it in the article if that's ok ;)

Is there a benefit to building C code with a C++ compiler?

Re: How to write better game libraries

#112

Post by rumanator »

eru wrote: post #57
je42 wrote: post #43

Earlier quoted context omitted.

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

> Templates are duck typing at C++ compile time (which is their runtime).

That description only applies of you venture into the dark realm of template metaprogramming, and anyone who ventures into those lands is wise enough to understand that the tool is not the one to blame if one decides to abuse a feature to apply it in a way it was not (initially) designed to be used.

Re: How to write better game libraries

#113

Post by matheusmoreira »

LucaSas wrote: post #70
yoz-y wrote: post #69

> Not everyone wants to use C++ (some prefer C). This could be very well flipped over. If I have the source available, I'd much rather deal with C++ bindings.

Hi, I mention in the article that "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." which is where the advice comes from.

Because the binary interfaces generated by C libraries are simple and therefore universally supported. It's just normal symbols and calling conventions. Conforming to this ABI benefits users of every other language, not just C++.

C++ ABIs are rather complex and much harder to interface with. The existence of concepts like virtual functions and exceptions significantly complicates the implementation of foreign language interfaces.

https://wiki.osdev.org/System_V_ABI https://itanium-cxx-abi.github.io/cxx-abi/abi.html

Re: How to write better game libraries

#114

Post by colonwqbang »

matheusmoreira wrote: post #111
LucaSas wrote: post #89

Earlier quoted context omitted.

Thanks for the comment, I might steal your "subset of C99 which compiles both in C and C++ mode on GCC, clang and MSVC" quote and put it in the article if that's ok ;)

Is there a benefit to building C code with a C++ compiler?

Only if your project is already mostly C++ and you would like to use your C++ compiler for everything, to keep the build process simpler.

Re: How to write better game libraries

#115

Post by abnercoimbre »

pjmlp wrote: post #107
erikbye wrote: post #103

Earlier quoted context omitted.

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.

The earlier comment was misinformed. Handmade Network is inspired by the series, yes, but stands on its own and embraces new languages and very different projects. See the Handmade conference[0] for examples.

[0] https://handmade-seattle.com

Re: How to write better game libraries

#116

Post by eru »

rumanator wrote: post #112
eru wrote: post #57

Earlier quoted context omitted.

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.

> Templates are duck typing at C++ compile time (which is their runtime). That description only applies of you venture into the dark realm of template metaprogramming, and anyone who ventures into those lands is wise enough to understand that the tool is not the one to blame if one decides to abuse a feature to apply it in a way it was not (initially) designed to be used.

Template metaprogramming makes things harder, but even in the most boring C++ hello world program, you have someone misusing a bit-shift operator for IO.

Concepts would presumably enforce some kind of thematic relationship between different overloads for the same group of functions and operators. (At least that's how we are doing it in Haskell with typeclasses. But we have a more forgiving syntax that allows us to make new operators.)

Re: How to write better game libraries

#117

Post by comex »

oriolid wrote: post #86
Const-me wrote: post #56

Earlier quoted context omitted.

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

That developer must be misinformed. I have been developing a native component that needs to interface with C++ APIs from the app and Objective C APIs from iOS. The only thing you need to remember is to not mix exceptions from C++ and Objective C. The object models are also incompatible, but the compiler prevents you from mixing them.

Also, if C++ is only used in the library implementation... you wouldn't even need Objective-C++ unless you needed to add Objective-C API calls to the library's own source files. Otherwise, you could just compile the library's source files as regular C++, and link them together with your Objective-C code. This works exactly the same way as combining C and C++, and Xcode (the IDE) has no issue with it. So it seems very likely that the developer was misinformed.

Re: How to write better game libraries

#118

Post by LessDmesg »

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…

Just a few days ago I've read accounts of C++ projects compiling for hours because C++ has a buggy compilation process, e.g. it copies and pastes every header everywhere instead of only one copy. Don't blame developers for obviously flawed language standards.

Templates are of course type unsafe, I'm not sure why you're lying while also admitting that they will only become type-safe in C++20.

Circular references deserves more comment: there is a difference between unmanaged and managed memory. C is unapologetically unmanaged, which cements its position on the embedded scene. But C++ has tried to be the in-between language: you have your raw pointers, and you have your refcount GC (“smart pointers"). And the thing that strikes me is the Cppistas have overwhelmingly chosen GC, but their language's GC is the worst kind, with circular references, performance costs (yes, smart pointers have a lot) and ultimately without memory safety (as raw pointers are still there). They've truly chosen tge worst of both worlds yet don't have the integrity to admit that the future is with managed, traced GC. C++ is like driving a car from the fifties and bragging about how comfortable and modern it is with that new internal combustion engine!

Re: How to write better game libraries

#119

Post by LessDmesg »

rumanator wrote: post #112
eru wrote: post #57

Earlier quoted context omitted.

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.

> Templates are duck typing at C++ compile time (which is their runtime). That description only applies of you venture into the dark realm of template metaprogramming, and anyone who ventures into those lands is wise enough to understand that the tool is not the one to blame if one decides to abuse a feature to apply it in a way it was not (initially) designed to be used.

You must be trolling... Templates in C++ ARE for metarogramming. The fact that they work as a glorified text substitution (and they are only coming around to fix them in 2020) leaves no apology for the tool.

Re: How to write better game libraries

#120

Post by nurettin »

Reelin wrote: post #4
nurettin wrote: post #3

>> C is the lingua franca of programming I don't have the exact numbers, but this seems debatable.

It's the lingua franca in that it's the standard for interoperating. Every high level language I've used has had at least one C FFI readily available.

We do have a mutual understanding on whether C foreign function interfaces are available for other programming languages, which does enable languages to send system requests (for systems which are written in C) or to create optimized C code to parse documents or calculate formulas. I am aware that the concept of making languages talk with C interfaces exist. And I made the above statement knowing this.
Post reply on HN