When I work on my personal projects, I program in C using a small amount of libraries for specific things. To compile, I use a unity-build: Everything is compiled within a single compilation unit; the main .c-file includes other .c- and .h-files. This vastly simplifies the compilation process, such that my "build-system" is just a single build.sh-script.

While this approach works fantastically for me, I used to think that this is only feasible for small projects. "This doesn't scale" or "This doesn't support x" is thrown around a lot. After all, compile any somewhat popular open source project, and you'll find a combination of

• Ninja
• cmake
• make
• meson
• Visual Studio Project / Solution Files

In contrast to my personal projects, I have worked on some larger projects for my bachelor thesis, student assistant job and now at a company as a full time software developer. These projects span from ~20k LoC, to somewhat recently started projects using C++, C++/CLR and C# (for backend, interop and frontend, respectively), to ~1 million LoC of hacky mess of C++ code.

There isn't a single instance in which I don't miss my simple setup.

I wish I could say that the mountain of complexity that is introduced to these projects comes with a tremendous amount of benefits, but from my point of view, the upsides are pretty limited.

The tooling, while supporting what feels like a billion different things, always falls short for the usecases we need, while containing a lot of baggage in terms of complexity, lacking ease-of-use, prone to failure, speed, and lack of flexibility, as soon as you do anything that deviates from the trivial case.

Anecdote Visual Studio

This software is so unbelievably fucking slow, at every fucking opportunity. Opening files? Finding stuff? Slow. Jumping around? Slow. Need to install an update? 30min down the drain, if not more if you skipped a bunch.

The information density of the software is also dogshit. "Compilation error in this header". Understandable - now, which .cpp did you try to compile when that error occured? It doesn't know; or rather it doesn't want to tell me, for some reason. It is easier + faster to copy the behemoth of a msbuild.exe compilation command into a console, and see which compilation step failed.

Visual Studio comes with a bunch of optional features and support, like Google Test (GTest) and Address Sanitizers (ASAN for short). If you enable ASAN on your project and run the program from the Visual Studio debugger, it will crash and complain about a missing DLL. Enabling ASAN is done using a drop-down option, but there is

• no out-of-the-box support for actually running the software, if Visual Studio / the software wasn't started from the developer console environment
• no indication that you have to do that
• no mention of where the DLL is located
• no automatic copying of the DLL next to the resuling program

Other fun thing: You can enable ASAN for DLLs, which you can reference from a C# project to execute native code. No complaints from the compiler, linker, nor Visual Studio. But even if the DLL is part of PATH, the C# program crashes. Even if you copy the DLL over, the program crashes.

And googling reveals that in order to be able to use ASAN with C#, you'd have to compile the entire C# runtime with ASAN support enabled.

As if this wasn't already a huge waste of my time, here's another fun story:

Visual Studio offers both configurations (by default: "Debug" and "Release"), and the target architecture (e.g. "Win32" and "x64"). But you are free to add your own configurations! Visual Studio even provides a handy "copy configuration from"-optio, such that I can e.g. create a separate Debug_Clang or Release_ASAN configuration, such that I can contain my changes to these configurations and be able to quickly switch between them.

But as soon as you do that in conjunction with GTest, your debug builds will fail. Why? Because the linking is done using some XML-configuration files (kill me), which conditionally reference the libraries you need to link to depending on the configuration name. If your configuration is called "Debug", it's linking against the debug libraries of GTest. For all other configuration names, it's using the release version. And there doesn't seem to be a way to overwrite this behavior in the Visual Studio UI. And here's the best part: This has been an issue since 2019, with no plans of fixing it. Ironically enough, I encountered the same issue when using the C++ package manager Conan; but hey, at least that one is open source.

The Problem In General

It feels like as soon as you buy into a complicated system like Visual Studio / large build environments, or languages like modern C++ with paradigms like OOP, you are not spending time fixing actual problems. Instead, a large amount of time is wasted on trying to fix issues which shouldn't exist in the first place.

With C, I have a simple language, including its various shortcomings. There is not a lot of hidden things going on (in comparison to other languages). I don't need to think about memory management thanks to arenas. For the most part, I have a decent control over what I want the computer to do.

With "professional", modern C++, the language is a mess:

• The compilation time of large, templated projects quickly grows out of hand.
• In order to solve the memory issues I didn't have beforehand, everyone is advised to use std::unique_ptr<...> and std::shared_ptr<...> everywhere.
• In order to solve the various casting problems I didn't have beforehand, you are instructed to use one of
  • std::static_cast<..>,
  • std::dynamic_cast<..>,
  • std::reinterpret_cast<..>, or
  • std::bit_cast<..>,
  as C-style casts are considered "bad practice".
• Usage of const whenever possible aims to prevent bugs I didn't have, and might force the use of std::const_cast<...>, which I didn't need.
• Zero-Cost abstractions and possible performance optimizations using const, which don't happen in practice, are parroted, but let's fragment the memory some more and create more objects. After all, it's "easier" and "more modern" that way.
• Classes and Structs are now used to tightly couple data to behavior. It becomes impossibly difficult to understand the data and the operations one is working with. Separating these two turns, which you get by default in C, turns into a long-term problem, spanning over several sprints.
• While -Wall -Wextra -Werror used to have me covered, the implicit conversions happening everywhere warrants the introduction of the explicit keyword for most constructors, for situations I didn't use to have.
• The introduction of OOP with v-tables blurries the explicit data layout of a class / structure. In order to cope with the plenty newly introduced pitfalls (while I'm still waiting for the benefits to become apparent), people come up with stuff like Rule of Three or Rule of Five.

Feel free to add to the list. These are the ones I can come up with on the spot. I hope it illustrates how buying into a set of beliefs / working within a certain environment redirects a lot of energy to discussing strategies and coming up with solutions for problems that you could also just avoid altogether.

And for those that still claim that this is simply required for large scale projects, checkout the C/C++ debugger RadDbg:

• Written in C
• Compiled in a single (or at least very few compilation units)
• Dependencies are contained in the repository [0]
• Build system is build.bat for Windows and a build.sh for Linux
• To preprocess data, a meta-program is compiled and executed, before the main application is compiled. I'm currently trying incorporate this simple idea into my projects. So far, I'm very pleased with the results and flexibility.
• The sofware is fast (and pretty!)