How to write better game libraries • Hacker News Board

Re: How to write better game libraries

#121

Post by rumanator » Mon, Dec 09, 2019, 8:51 AM UTC

LessDmesg wrote: post #119

rumanator wrote: post #112

Earlier quoted context omitted.

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

> You must be trolling... Templates in C++ ARE for metarogramming.

That's an ignorant statement both wrt generic programming (you know, the whole purpose of C++ templates) as well as the history of C++, in particularly how C++ template metaprogramming was discovered by accident after C++ templates were already implemented, widely used (see the STL), and standardized.

Re: How to write better game libraries

#122

Post by honestoHeminway » Mon, Dec 09, 2019, 9:15 AM UTC

rumanator wrote: post #110

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?

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

Its the implementation, not the system fallacy.

Re: How to write better game libraries

#123

Post by LucaSas » Mon, Dec 09, 2019, 10:44 AM UTC

shmerl wrote: post #88

LucaSas wrote: post #85

Earlier quoted context omitted.

Hi, the reason for using C99 is that it is fully compatible with other languages. If you write a library in Rust you might be tempted to use Rust only feature which will then make it hard to wrap the library for other languages. And if you don't use those features from Rust in your library people will comment that your library isn't Rust enough. Same thing applies to C++. To that extent my advice is to write C in C r…

I suppose wrapping it for other languages can be harder, but should be doable I think. The benefit of Rust though is using a much better language with rich standard library. As for toolchain, Rust can be set up basically anywhere llvm can, which is quite a lot. There are rare cases where llvm wasn't ported yet to, but I don't think they are enough to make C a compelling option in general, and I don't think any of the…

I think the Rust standard library is actually a liability in this case, not an advantage. The rust stdlib will essentially be an extra dependency and also the rust standard library doesn't have allocators, so unless you are very careful you might violate the principle of not doing allocations for the user. Also, even if it did have allocators, passing allocators from to Rust via a C interface would probably be awkward.

So if you do choose to make the implementation in another language, there are extra considerations that you have to take into account.

Re: How to write better game libraries

#124

Post by jstimpfle » Mon, Dec 09, 2019, 2:12 PM UTC

pjmlp wrote: post #106

jstimpfle wrote: post #93

Earlier quoted context omitted.

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.

If you like random links, here is another one... https://news.ycombinator.com/item?id=21741504

Re: How to write better game libraries

#125

Post by pjmlp » Mon, Dec 09, 2019, 2:24 PM UTC

jstimpfle wrote: post #124

pjmlp wrote: post #106

Earlier quoted context omitted.

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.

If you like random links, here is another one... https://news.ycombinator.com/item?id=21741504

The difference being that my links have to do with damage C keeps bringing into IT and the respective monetary losses.

They are not random, only to those that don't care about improving the quality of our eco-system.

Software liability couldn't come soon enough.

Re: How to write better game libraries

#126

Post by EliRivers » Mon, Dec 09, 2019, 3:46 PM UTC

a_t48 wrote: post #98

EliRivers wrote: post #73

Earlier quoted context omitted.

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?

Off the top of my head, just listing a handful of various projects; a commercial static analyser, various GUIs, a broadcast industry projectile tracking and information presenting system, a multiple networked radar (and similar) network data fusion project, broadcast automation software, various data processing and display software sets, software simulating mechanical movement for artificial test data generation, image processing and morphing. I could go on, but hopefully that gives a flavour. A whole big bag of things.

From my perspective, banning exceptions is the exception (a ha ha); not the rule. I've worked on embedded software that (I expect) didn't support exceptions in the provided compiler, but I don't consider that an explicit ban on exceptions - they simply weren't possible.

Re: How to write better game libraries

#127

Post by jstimpfle » Mon, Dec 09, 2019, 4:29 PM UTC

pjmlp wrote: post #125

jstimpfle wrote: post #124

Earlier quoted context omitted.

If you like random links, here is another one... https://news.ycombinator.com/item?id=21741504

The difference being that my links have to do with damage C keeps bringing into IT and the respective monetary losses. They are not random, only to those that don't care about improving the quality of our eco-system. Software liability couldn't come soon enough.

What do you think are the monetary losses by unmaintainable software, resulting in bad and extremely unsafe practices (not related to memory, but...) like in my link? What do you think are the monetary losses from developers going mentally ill because they don't understand and don't like the shit they're doing?

Re: How to write better game libraries

#128

Post by flohofwoe » Mon, Dec 09, 2019, 9:03 PM UTC

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?

C++ has some stricter type checking by default, but most of this can be achieved by raising the warning level when compiled as C.

Nevertheless I received enough requests to make my C libraries 'C++ compliant' that I gave in :)

Re: How to write better game libraries

#129

Post by derefr » Tue, Dec 10, 2019, 4:32 PM UTC

NohatCoder wrote: post #37

It always baffles me when a library comes with its own arcane build code. Instructions like "Requires Python" invariably turn out to actually mean "Requires hours of debugging".

The problem is that C is a "lingua franca" and yet has no inherent facility for compile-time codegen (i.e. "real", grammar-level macros, as opposed to C's lever-level macros), so you need something else (whether that be the venerable m4 or yacc, or random Python scripts) to serve as your substitute for "real" macros.

In languages that do have "real" macros, you don't see the same problem. (On the other hand, in most of them, you see a need to call out to a C compiler to generate FFI code, which is sometimes just as bad when you're using a PL with a managed runtime and your build-env didn't otherwise have any need for a C toolchain.)