> 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<i>).<p>You use unique_ptr and shared_ptr because float</i> is unsafe. If you don't care about the safety that smart pointers provide, you can use float* in C++ too.<p>> 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;<p>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.<p>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.<p>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.
Yesterday I finished a complex library in C++20, which I wrote "Rust style" by following the ISO C++ guidelines. I used 0 `new`, no smart pointers, all by-value returns, move semantics and STL containers. It literally took a month to write, but it worked as expected at the second attempt (first failed due to forgetting a `}` in a format string). I did not see a single segmentation fault and it works fine on both Linux and Windows. Rust and modern C++ give you the expressivity to describe what you want to accomplish to the compiler.<p>You can use the type system to erase certain classes of error entirely, without ever having to worry about something pointing to bad memory or whatever. If you follow certain rules, C++ can be _almost_ as safe as Rust.<p>I love C personally, and I've been coding in it for more than a decade now. It is simple, easy to learn, but it gives you literally zero ways to create abstractions. That could be a good thing, until you realize that almost all complex C codebases reimplement (badly) half of the STL due to libc providing no containers of sort. Linked lists are terrible for performance, yet C programs are pestered with them due to how simple they are to implement. And I won't get started with C strings, which are just a historical BadIdea™.<p>Most C codebases tend naturally to evolve into a mishmash of reinventing the wheel and ugly macro magic. After all it's either that or to risk committing preventable mistakes all over.<p>That's not without saying that C++ is that better - every three years a new release comes out and fixes certain issues so vastly that it completely changes how you are supposed to write code (see string_view, or concepts). That's not without saying that the language is also full of old cruft no one should ever think about using.
I like to think of a compiler as a virtual machine whose instructions are the tokens in your code, and whose output is object code. Taken that way, you can <i>for sure</i> optimize the input program (your C++) to execute faster on the interpreter (the compiler). Understanding how the language (any language with such features) is implemented lets you stray away from the slow parts.<p>For instance, in C, every function has a unique, global name. That means the implementation in the compiler can be a hash-table from string to implementation. C++ allows function overloading; now, our 'hash table' is a much more complicated thing: first, we must consider every function in the overload set no matter what; second, we must pick which function is "best" — usually through some complicated unification scheme. In all, this means that C function lookup is O(1) (probabilistic), whereas C++ function lookup is O(n) <i>at best</i>, but with unification it might be O(n^2) or O(n^3). I've seen slow compiling code with <i>hundreds</i> of identically named functions.<p>Templates are slow for two reasons: (1) they get shared via header files, so they get reparsed over-and-over-and-over; and, (2) they're implemented with a stringy interpreter whose job is to instantiate copies of the code. This is distinctly slower than macro expansion; generally, macro instantiation is of <i>code</i> and so occurs in source files — only requiring a single parse; and, also, there's just string-replacement, not an interpreter.<p>But ... here's the thing. You can make your C++ code compile fast by simply <i>not using slow paths</i> through the compiler.
I used C++ for a good while (systems programming). I like it and still use it for some things. But when I started using Go, I used C++ less and less. Go was simple like C and almost as fast.<p>There is a time and a place for all languages, but if I could only have one, I'd probably pick C++. It can do almost anything in whatever programming style you prefer. It really is the most generic language I've ever used. That's both its strength and weakness.<p>Also, the fact that C++ is standardized (ISO) and not controlled by a company (Google, Microsoft, Apple) I feel it offers greater freedom. No vendor lock-in.
The author lists GLFW, stb_image, and ImGui as dependencies for their renderer written in C. Those are the same exact dependencies you would use to write a renderer in C++. Maybe you would add glm because you don't want write matrix math operations, but the author will have to do that in C anyway. I don't see how dependencies are an advantage for C.
If you really like the simplicity of C I highly recommend Nim:<p>* Compiles to C, so you stand on the shoulders of giants wrt compilers.<p>* Very low overhead GC that doesn't "stop the world".<p>I was working on a project recently where I had to just write a bunch of stuff to disk, and I tried Node, and then Java, and they were about the same, and I figured - yep, makes sense, it's IO bound.<p>Nim got twice the throughput w/ an order of magnitude less memory usage! Because the serialization I suppose was the bottleneck and msgpack4nim is pretty fast.
I wonder what kind of hardware OP runs on, and which compiler is used.<p>Here on my laptop (Intel(R) Core(TM) i7-8750H CPU @ 2.20GHz), on linux, compiling an eigen example takes 0.7 seconds<p><pre><code> clang++ -fuse-ld=lld eigen.cpp -I/usr/include/eigen3/ 0,66s user 0,07s system 100% cpu 0,728 total
</code></pre>
if I put the eigen header in a PCH this drops to 0.1 seconds<p><pre><code> clang++ -fuse-ld=lld eigen.cpp -I/usr/include/eigen3/ -include-pch 0,08s user 0,02s system 104% cpu 0,099 total
</code></pre>
I have a hard time seeing how 300 lines of code (vs the 10 lines of the example) would multiply compile times by 300 - here's the example I used<p><pre><code> #include <iostream>
#include <Eigen/Dense>
using Eigen::MatrixXd;
int main()
{
MatrixXd m(2,2);
m(0,0) = 3;
m(1,0) = 2.5;
m(0,1) = -1;
m(1,1) = m(1,0) + m(0,1);
std::cout << m << std::endl;
}
</code></pre>
I develop a GUI software with boost, Qt, and a fair amount of TMP and my average turn-around time from a change in the average file to the program running is between in and 2 seconds. Maybe it could get down to 0.1~ seconds if using C, but there would be so many less checks and guards !
>So what is the bare minimum? To use the GPU, I need a graphics API. Vulkan is the one that is most widely supported so that is a natural choice<p>Vulkan can't possibly be the most widely supported graphics API can it? I have to imagine that targeting older hardware is better with OpenGL because it's been around forever, but I don't actually know and a quick google search doesn't turn up much.
I can relate a lot to this as an old school C++ developer (not anymore). I also remember switching a project over to pure C some years ago and found it a lot more pleasant to work with. But I combined it with Lua so I could use Lua for high level constructs C is not so good at.<p>Anyway I suspect that in a few years Zig will be the choice in scenarios like this. It gives you fast compilation times and low level access like C while being a lot safer, but without adding C++ level complexity.<p>That is an important sweet spot to hit.
I've always been impressed by Go's compile times. The first few times I thought I'd made a mistake, and it was doing nothing (the prompt came back so quickly). Now I know better :-)
>linking a big C++ project with lots of dependencies and some template magic can easily take several minutes.<p><i>dreams wistfully of C++ build that only takes several minutes</i>
Often the C vs C++ debate comes down to a religious war where the C side is arguing that their hammer is best for pounding in nails and the C++ side is arguing that their screwdriver is best for screwing in screws. I don't believe they're suited for the same purposes at all.<p>If you're writing code where you need to interface with the hardware directly (embedded), or manipulate things in kernel-space efficiently (OpenGL, audio, games), then C makes a lot of sense (and if you try to write C++, you'll end up using C anyway, and your attempts to shoehorn in C++ features will be ineffective).<p>If you're writing a high-performance C++ version of a Python web service, C++'s nicer memory management and string handling will be very VERY useful, not to mention object types for serializing/deserializing data.
If you want a good case study in repositories that build quickly then check out cosmopolitan libc. Typing `make -j16` it compiles 15,383 .o objects, 69 .a static libraries, and 548 executables, 297 of which are test executables, which are also run by the make command, and all that takes just 40 sec.
I can understand the point about compile times. For the rest, C++ is just superior and you cand do what you would do in C, just safer and add constexpr, consteval and careful templates for more type safety plus more type safety by default.
Meanwhile, a data science project in python runs right up until it doesn’t, and the only help you have is heuristics for why your data maybe was bad.<p>I almost sort of envy compilation at times.
It seems like most of the issues with C++ are solved by not using the parts that suck. You can still write C++ as C-with-classes/RAII/operator overloads, and leave all the smart pointers and template meta-programming and boost (do people still use boost?) magic at the door.
I just freakin' <i>hate</i> .h files...
Writing pretty much the same thing but twice and in two different places for every function. Why?!?
I would love C++ if not for them.
Just sad.<p>If the language is not doing a great deal of your work for you, then you are not using it right. Doing it right, things flow fast and work right the first time. So, you don't care that it takes 30 seconds to compile, because you coded all afternoon and then compiled and it worked right away, with no debugging needed. After that, coding C feels like a big PITA where you have to tell the compiler everything over and over again, and need to compile every few minutes just not to get too far into the weeds.<p>Any big system has some objecty bits, but O-O is a technique, not a religion. Same for anything-oriented: functional, data-oriented, what-have-you. Master the tools, don't be mastered by them.