Comment by uecker
19 days ago
Why do you think working with a group of people on a C codebase introduces pain unlike other languages? Working with a group of people always causes pain, but I found the pain much less severe for C than for C++.
19 days ago
Why do you think working with a group of people on a C codebase introduces pain unlike other languages? Working with a group of people always causes pain, but I found the pain much less severe for C than for C++.
C relies on the programmer to understand the lifetime of every object in the program, which is global structure. When the programmer is multiple people, it's easy to get out of sync. unique_ptr from C++ solves 90% of this.
Ever use a leak detector? Even my graphics engines (with shared resources) uses a leak detector in debug mode. The monent you forget to release a resource, assertion at program termination.
Leaks are trapped with tooling, and all you need is one dev in the team to be diligant to run valgrind or visual leak detector or similar.
We run valgrind and asan as part of the CI, so it is checked before every merge and no developer has to be particularly diligent. But it is also not something that triggers a lot.
Do you think the best way to avoid bugs is to thoroughly test your code, or does understanding the code while you write it also help?
It depends on what you're building with the language too.
For eg. In very embedded contexts where we were not using any big data structures like struct of strings, not doing any memory allocations etc... C might be easier to reason about than C++. (No hidden code paths). Just allocate something on the stack, pass the pointer to a function to do the computation, done.
In any desktop apis (gui, web servers etc..), where you deal with collections of objects, need to spin up thread pools and rely on results from the future etc... The standard library data structures (vectors, maps etc...) alone makes C++ code a lot more easy to read and review than C. When raw pointers are forbidden, Ownership of memory becomes very clear. Granted my opinion of desktop development comes mostly from very few libraries (Qt vs. Gtk, gstreamer's C API vs. C++ wrapper, http libraries etc...), but there are some problem domains for which C is just insufficient.
Your question also hides an answer. You don't often get to chose a group of people you work with, and unlike projects that self-attract and self-distill ideal profile (like linux mentioned in sister comment), you're left with people usually not used to ye olde C idioms. With C++ it's a bit easier since it is more widespread and supports some of the idioms people get used through schools and other projects. Of course, projects (should) always dictate a certain discipline by different mechanisms, but if certain way of thinking isn't ingrained then it introduces just that much more pain to the communication layer between people.
I would argue that is is much harder to find a group of C++ programmers who write a coherent style of C++. In C there is not nearly as much to decide. Note also that I am speaking from experience with both.
In my mind using a simpler language should be less painful given there is less to argue about given syntax and versions etc. Take c# for example you have multiple ways to do the same sort of things.