Garbage collectors vs.efficiency and flexibility

If all this is such a good idea, why didn’t they do the same thing in C++? Well of course
there’s a price you pay for all this programming convenience, and that price is run-time
overhead. As mentioned before, in C++ you can create objects on the stack, and in this case
they’re automatically cleaned up (but you don’t have the flexibility of creating as many as
you want at run-time). Creating objects on the stack is the most efficient way to allocate
storage for objects and to free that storage. Creating objects on the heap can be much more
expensive. Always inheriting from a base class and making all function calls polymorphic
also exacts a small toll. But the garbage collector is a particular problem because you never
quite know when it’s going to start up or how long it will take. This means that there’s an
inconsistency in the rate of execution of a Java program, so you can’t use it in certain
situations, such as when the rate of execution of a program is uniformly critical. (These are
generally called real time programs, although not all real-time programming problems are
this stringent.)7
The designers of the C++ language, trying to woo C programmers (and most successfully, at
that), did not want to add any features to the language that would impact the speed or the
use of C++ in any situation where C might be used. This goal was realized, but at the price
of greater complexity when programming in C++. Java is simpler than C++, but the
tradeoff is in efficiency and sometimes applicability. For a significant portion of
programming problems, however, Java is often the superior choice.