> Where C++ gives you many slightly different takes on the same concept (e.g. unique_ptr, shared_ptr and raw pointers), C gives you one way to go and that one has a conveniently compact notation (such as float).

You use unique_ptr and shared_ptr because float is unsafe. If you don't care about the safety that smart pointers provide, you can use float* in C++ too.

> ticking with the example of matrix math, it is baffling how C code is often more compact and readable than C++ code. A matrix declaration would be float matrix[4][4]; [...] Of course, you could take the same approach in C++ but then you are not really using C++. The example from above in C could be simply: float* top = matrix;

But that's not that same thing, is it? I fail to see how you're actually getting the top 3 rows there; you're just assigning a pointer. Again, you're making your code less safe and expressive by using no abstraction at all.

And please, how is `matrix_add(matrix_mul(A, B), c)` more compact and readable than `A*B + c`? And this is being kind to the C version.

If the problem is with C++'s compilation times, then it's perfectly reasonable; this is one of the major problems of the language. But using unsafe constructs and then saying that they're better than C++'s safer alternatives is just comparing apples to oranges.

The problem is not even just safety. You can write safe C, if you are careful (and you need to be careful also for C++, smart pointers do not just magically make everything right). The point is that OP makes the point that C requires to write less code, and this doesn't even seem true: you have to remember, each time some non-trivial object goes out of scope, to call its destructor/deallocator, which results in a lot of code (which can at times hard to read, especially if you have not completely linear control flow). Looking at just the declaration is a small part of the issue.

It is possible to write safe-C, but C is far more error prone than C++. C has more implicit type conversions than C++, which may results in bugs and undefined behaviours. C lacks RAII (Resource-Acquisition Is Initialization) that is useful for memory and resource management. C will actually require more code than C++ since, the C standard library lacks generic data structures such as vectors, hash maps, linked lists and so on. The implementation of those data structures requires lots of preprocessor macro hacks.

It is possible to write safe C, only if one uses static analysis tools and undefined behaviour sanitizers. In the case presented by the article, as it is related to game, safety does not matter much, unlike device drivers, operating systems or embedded systems where C bugs can introduce security vulnerabilities.

Regarding the compile-time complaint, it is possible to reduce the compile-time by using forward declarations; forward template declarations; template forced instantiation and isolating large parts of a project in a static library using CMake.

> C is far more error prone than C++

I don't know about that... C++ (both the language and the library) is orders of magnitude more complex, and the opportunities to make mistakes have grown almost proportionally. (Two characteristic examples recently discussed here on HN: auto references and iterator invalidation.)

But C lacks even strings, lots of C bugs and vulnerabilities are related to memory management, memory ownership and string handling. Even the C subset of C++ is better than C since it at least has more explicit type conversions that forces the developer to state his or her intent. One example of the C string problem is the strcpy(buffer, char* string) that copies a string to a buffer. If an external actor discovers how to manipulate the string size, he or she can take advantage of this buffer overflow vulnerability and even execute arbitrary code remotely if it is used in a server. If the application with this problem is a file, one create a specially crafted file to take advantage of this design flaw.

However using C in the case of the original poster does not matter much as the application is game-related not subject to untrusted input.

It is pity there is no alternative "standard library" with safer data struct and operations.

There are some attempts, for example, relatively wildly known klib: https://github.com/attractivechaos/klib