IMO C++ despite its warts is easier to avoid mismanaging memory than C. RAII and smart pointers are very useful. Fewer off by one errors leading to buffer overflows as well in my experience due to things like iterators.
I'm pretty well versed in C++, and every time I try to write something in C, I fall back to C++. I find memory management a pain without RAII, error handling a hassle without exceptions, and, well, anything really a pain without some sort of standard container library.
I have the idea that there's good alternatives for these in C-land, but I'm unfamiliar with them and would love for an expert to teach me.
In general, I wonder whether there's really that many people who know C but not C++. This might just be me projecting myself onto the world, though. Anyone?
Tricky. I prefer C and use it at home for fun. C++ is strictly for work. But I also like to program in ways that are safe by construction, and C++ gives me tools like unique_ptr and std::vector for doing that.
But I agree those tools are limited. The class of bugs which C++ protects you from are the shallow ones. Coding with discipline will prevent more bugs than switching to C++.
Languages with real memory safety however are a genunie step up. Rust for example makes it painful to not code with discipline. Unfortunately I find it makes programing painful in general -- so I am still waiting for a safe language that is as much fun as C.
Is C/C++ really such a better choice in safety-critical systems? It's notorious for having all sorts of buffer overflows and memory issues on unexpected input.
Or do what you want. However I think c++ with just RAII and smart pointers brings so much more safety than C I don't know why it doesn't get more attention. You don't have to use all the rest, just those couple of things can bring a lot of safety to a project
I spent a few years coding C after using C++. The cognitive load needed to keep code correct was crushing, and switching back to C++ was massively liberating.
I didn't code any memory leaks, use-after-frees, or buffer overruns, but the effort to avoid them was ever-present, a continual drag and distraction from what the code was meant to achieve.
You say that C / C++ is bad. You assume that there are alternatives that are just better. I think you are wrong.
Why? The short answer is: there is no free lunch. There is no silver bullet.
C / C++ has huge pitfalls with its memory management. But it is also a well-designed programming language with a great balance between efficiency and comprehensibility (and all other features of a language).
Every design decision in a language is a trade-off. And the trade-offs in C / C++ are so well chosen that there was no easy improvement for decades. No low hanging fruit. A C programmer has to understand much more about memory management because there is no virtual machine / garbage collector / interpreter running which takes care of it. But for that you get efficiency that is not possible by design with the other approaches.
For me C / C++ made the best trade-off.
Until Rust came along. Rust wants to make the memory management 10% better than C++ with 0% loss in efficiency. That is huge. No one reached something similar in 40 years. I am sceptical because this is such an ambitious undertaking. If that really works in real life I will be impressed.
What good programs are written in C that don't have well-structured memory management the way C++ does it with RAII?
Edit:
"But in reality, why C is still the best programming language for large projects (IMO) is exactly that the programmer is allowed to choose a suitable structure, such that the program can fulfill the technical requirements. Other languages force the project into a structure that somehow never fits after a couple thousand LOC."
Yeah, this doesn't make any sense. The reason is, C++ doesn't impose anything on your program structure that C doesn't, while C, with the limitations it has, imposes a tax on all sorts of ways of structuring your program.
For example, you can't practically write a program using a futures library (such as the Seastar framework) in C. And every program you write in sensibly written C can be translated to C++. The exception might be really really small-scale embedded stuff that doesn't allocate memory.
I really enjoy coding in C (it's probably the language I know the best) and I think C++ is an over-engineered and bloated language, however I'd still pick the latter for something like that. Or rather, like most devs, I'd pick a decently small subset of C++. The main reason for that is that in C if you need a data structure that's more involved that a simple contiguous array then you're on your own. A linked list is sort of not too bad to implement (the kernel's list.h is easy to use and reuse for instance) however as soon as you want things like hash tables, trees or anything that benefits from RAII IMO it becomes a pain to manage everything. It's perfectly possible to do all of that in C (or hell, in assembly if you want to) but in my experience it will take a lot of time to implement correctly (and since you don't have generics it's harder to have general purpose structures that you can reuse easily) and it'll have worse ergonomics because of a lack of destructors and other RAII patterns.
In my experience C is great for low level things (dealing with hardware, writing small low level services etc...). You don't have to deal with too many abstraction layers, memory management is generally straight forward (your average driver won't usually deal with anything more complex than a buffer queue or ring). For the type of application the author is talking about he'll probably have to deal with rather abstract data structure holding the state of the game, "a fluid flow of information coming into the app and going out of the app", concurrency issues etc...
Is it possible to do all that in C? Undoubtedly. If I was tasked to implement something like that would I choose C ? Hell now. I'd probably go with a subset of C++ like I mentioned before, Rust if the dependencies I needed were available (or I didn't mind coding them myself) or maybe even Python if I wanted to reduce development time as much as possible to get a PoC implementation live as fast as possible.
C++ gives you an embarrassment of footgun riches above and beyond what C provides. On the other hand, idiomatic modern C++ also deftly avoids many of the C pitfalls. e.g. You don't ever touch new, delete, or raw pointers — instead favouring RAII-based smart pointers, and references. You avoid arrays in favour of vectors. This style (as opposed to old-school C-with-classes C++) is way more productive, and way safer.
modern-ish C++ has some tools that can make it easier, but fundamentally it's still unsafe, it's still proven pretty difficult to write a large C++ codebase without memory safety issues. (that said I would still personally prefer C++ to C, though the recent updates to the standard contain at best very small improvements from my point of view)
C++ is not bad. I think it sits in the middle between C and GC languages. I actually like what C++ offers. Languages with GC are actually easy to debug. I remember once I had my own memory management code, suddenly the write beyond boundary is not segfaulting any more, took me more time to figure out the problem.
I would argue that most of the memory errors actually pertain to C programs, not C++ ones (providing they use proper encapsulation and libraries such as STL).
C is syntactically C++ being a subset of C++ and I've seen many programs which claim to be C++ but are actually programmed using C methodologies.
Speaking from my own very limited experience, I think C++ can be pretty nice if you basically write straight C but borrow from the C++ STL. Smart pointers (std::unique_ptr, std::shared_ptr, etc), collections (std::vector, std::unordered_map, std::set, std::stack, std::priority_queue), and stuff like std::tuple and std::optional really make C feel less clunky without getting too gross.
This. C++ is awful in many ways, but it can be much nicer than C for writing _application_ code. Use RAII, avoid deep class hierarchies, restrict yourself to the STL and use smart pointer types for lifecycle management. That’s it for starters, you will write much better code than in C.
Then you opt in to certain features like templates or operator overloading based on your bike shedding level.
reply