Let’s start by considering C++.
As an opt-in option in C++, it is technically possible to add garbage collection to C++, as long as it is clearly specified how it integrates with the language and with the existing memory management model. But as an always-on feature of C++, I would consider the addition of garbage collection go be a breaking change to the language.
Bjarne Stroustrup had hoped an optionally-enabled garbage collector would make it into recent standards. But even though it’s technically feasible to do, it has been tough to specify exactly how it would integrate with the existing language, and it has been tough to reach a consensus. To properly use an optional feature like this, software developers would need to have a crystal clear view of how it would work and how it would interact with traditional C++ memory management. And like an optimizer, the new garbage collector would likely need to have many sub-options to control how the garbage collector would work, to deal with a wide variety of project requirements. It’s all feasible, but it’s not easy to standardize, document, implement, learn, and use properly.
Tons of old and new C++ code is being used in mission-critical, real-time, embedded, memory-constrained environments. Unpredictable stalls for garbage collection are just plain unacceptable in many of these environments, and garbage collection can have a significant memory overhead cost. There are other considerations as well, but these are the big ones. So, if garbage collection were added to C++, it would need to be an opt-in option, always disabled by default.
Now, let’s address C.
C is even more heavily used in embedded systems with real-time requirements and tight memory constraints. Adding garbage collection to C would definitely have to be an opt-in option, but it’s an option that would likely find little to no practical use in real-world projects. The same arguments that applied to C++ apply to C here, but are magnified. While it’s possible to implement a garbage collector for C, I have never seen a reasonable need for it in the projects where C is employed.
Some advice: Use memory management in C and C++ as it is, and if you want/need (and can accept the costs of) garbage collection, then choose a language that already has garbage collection. For example, in embedded systems where real-time response is not an issue and memory is not as constrained, you could use garbage-collected C# on the . NET Micro Framework (NETMF) instead of using C or C++. But introduce real-time requirements and/or tighten the memory constraints, and you really need a non-garbage-collected language like C or C++.
More advice: Don’t be afraid of languages that don’t provide garbage collection. While they may require a bit more thought and planning, using them will give you more precise control and a better understanding of what’s really going on. And keep in mind that, even in a garbage-collected environment, you still need to worry about memory leaks and ensuring that memory resources are disposed of at the proper times. In fact, I’ve found that developers who understand and have used non-garbage-collected languages in real-world projects are better able to properly manage resources when they have to use a garbage-collected language.