Is it a design fault that C++ itself has no garbage collection?

Answer 1

It's a design choice, but not a fault!
C++ is all about giving control to the programmer, and since you can't control when the garbage cołlector runs in most languages, it is a bit at odds with C++'s design philosophy (and also potentially makes your programs less efficient!)

If you need garbage collection, C++ has smart pointers, which are a similar.

Answer 2

It's the programmers fault there is garbage to collect. You should be responsible to return all storage you allocate. Languages with garbage collection are just making up for poor programming techniques.

Answer 3

No, there is no need for garbage collection. It's often not the solution to the problem as Bjarne Stroustrup(creator of c++) says. With C++ we have RAII and smart pointers that include reference counting, which allows resources not being used anymore to automatically be deleted, even when being passed around everywhere. They are not just limited to memory either, they can be used on any resource such as file handles, sockets, com objects, custom classes, etc, unlike most garbage collectors.

Answer 4

C++ descendant - Java, look what They have made with GC. C++ simply gave You more control

Answer 5

I'd say it's a language / cultural engineering philosophy you subscribe to, or don't, complicated by practical concerns.

A closer examination wasn't your question, so for divers:
* RAII, stack unwinding and auto-cleanup in the (half dozen?) ways you can exit a C/C++ program:
https://stackoverflow.com/a/30251056 (from):
https://stackoverflow.com/questions/30250934/how-to-end-c-code

* Comprehensive GC examination (wealth of info all around the fence):
http://www.cs.cornell.edu/courses/cs312/2008sp/recitations/rec24.html

*And on doing what's right:
A language that secure-wiped all variables could help control this:
https://code.sololearn.com/cCyWhRHgLF0F/?ref=app
because of problems like this:
https://www.explainxkcd.com/wiki/index.php/1354:_Heartbleed_Explanation

But is a policy of just deallocating vs wiping the right approach or a fault...? see first sentence?

Answer 6

@~ swim ~ Security case in point, not nulling a sensitive value before it goes out of scope, then iterating the garbage collector:

https://code.sololearn.com/cVG9zVeRGd3N/?ref=app

Impact may be minimal, just a thought.

Answer 7

@~ swim ~
Ah, an idiom, sorry... one interpretation is:
A relevant example demonstrating a point (in this case, yours).

Answer 8

C++ gives a great degree of control over memory allocation/deallocation which can mean a lot in some niche environment and not much in common day to day apps.

Time has changed and nowadays there is less emphasis on memory scarcity than there was when C++ entered the market. Sill a great rock solid language!

Answer 9

Garbage collection can cause serious Performance issues, something that you really don't want in perfomance-oriented, compiled languages like C++(Imagine Airplane controls not reacting for a second because of GC(Ok thats a bit extreme but you get the idea)). C++ has also numerous memory allocation methods from C available (malloc, free...) to do the job manually and to give the programmer more control. It was a design choice, no mistake. Good question tough.

Answer 10

I'm tempted to say no until I think about how many memory allocation errors have frustrated me over the years.

Answer 11

Garbage collection scans the live objects to reclaim the dead objects, so it's efficiency is proportional to the amount of memory you are wasting. Generational collectors mitigate this a little, but the issue is still there.

Full collections can also cause long pauses. Concurrent or incremental collectors avoid this, but they have to start early, so you need to waste even more memory.

C++ offers vectors, unique/shared pointers etc that makes most memory management easy to do correctly, without the performance issues associated with garbage collection.

The RAII mechanism also performs non memory related cleanup, file handles, database connections etc. Finalizers cannot do what destructors do because you cannot just wait until you run out of memory before you clean this stuff up.

Now garbage collection is still a good thing overall, but there are many applications that should not be garbage collected.

Finally, garbage collectors for C++ do exist such as the Boehm collector.

Answer 12

Garbage collection was not widely used in earlier programming practice because it was thought it might be helpful to use the same memory address and it's value even though there was no direct coding connection between the modules.

Also many programs just didn't bother because of the poor collection utilities and earlier operating systems being less advanced.

These and other practices led to memory conflicts, "screens of death", and frequent reboots adversely affecting office productivity.

So garbage collection is a good idea and a characteristic of good programming practice. However, the collection timing must also be carefully managed to avoid slow response at times of peak processing performance demands such as air traffic control and industrial robotics or artificial intelligence.

Further, the performance and collection practices will vary between operating systems, cpu architecture, computing languages, interpreter vs compiled, and the quantity and timing of hardware control circuit calls versus softer logic.

In short, clean up after yourself using the best tools for the environment, pack out of the programming wilderness whatever you packed in, and share your resources with your neighborhood programs and services as a good neighbor.

Users can, and do, have an excellent feel for what is a well written and well behaved clean memory product.

Answer 13

The garbage collector lets Java be a bit more easy to use, as for the lack of memory issues. C++ is a lot more complex then Java but therefore a bit faster. But the complexity also leads to suffer from bugs and errors, but those can be detected by programs as checkmarx.

Answer 14

....