Implicit garbage collection could have been added in, but it just didn't make the cut. Probably due to not just implementation complications, but also due to people not being able to come to a general consensus fast enough.
A quote from Bjarne Stroustrup himself:
I had hoped that a garbage collector
which could be optionally enabled
would be part of C++0x, but there were
enough technical problems that I have
to make do with just a detailed
specification of how such a collector
integrates with the rest of the
language, if provided. As is the case
with essentially all C++0x features,
an experimental implementation exists.
There is a good discussion of the topic here.
General overview:
C++ is very powerful and allows you to do almost anything. For this reason it doesn't automatically push many things onto you that might impact performance. Garbage collection can be easily implemented with smart pointers (objects that wrap pointers with a reference count, which auto delete themselves when the reference count reaches 0).
C++ was built with competitors in mind that did not have garbage collection. Efficiency was the main concern that C++ had to fend off criticism from in comparison to C and others.
There are 2 types of garbage collection...
Explicit garbage collection:
C++0x will have garbage collection via pointers created with shared_ptr
If you want it you can use it, if you don't want it you aren't forced into using it.
You can currently use boost:shared_ptr as well if you don't want to wait for C++0x.
Implicit garbage collection:
It does not have transparent garbage collection though. It will be a focus point for future C++ specs though.
Why Tr1 doesn't have implicit garbage collection?
There are a lot of things that tr1 of C++0x should have had, Bjarne Stroustrup in previous interviews stated that tr1 didn't have as much as he would have liked.
Eric Lippert wrote a detailed blog post about this subject a while back (additionally comparing it to VBScript). More accurately, he wrote about JScript, which is Microsoft's own implementation of ECMAScript, although very similar to JavaScript. I would imagine that you can assume the vast majority of behaviour would be the same for the JavaScript engine of Internet Explorer. Of course, the implementation will vary from browser to browser, though I suspect you could take a number of the common principles and apply them to other browsers.
Quoted from that page:
JScript uses a nongenerational
mark-and-sweep garbage collector. It
works like this:
Every variable which is "in scope"
is called a "scavenger". A scavenger
may refer to a number, an object, a
string, whatever. We maintain a list
of scavengers -- variables are moved
on to the scav list when they come
into scope and off the scav list when
they go out of scope.
Every now and then the garbage
collector runs. First it puts a
"mark" on every object, variable,
string, etc – all the memory tracked
by the GC. (JScript uses the VARIANT
data structure internally and there
are plenty of extra unused bits in
that structure, so we just set one of
them.)
Second, it clears the mark on the
scavengers and the transitive closure
of scavenger references. So if a
scavenger object references a
nonscavenger object then we clear the
bits on the nonscavenger, and on
everything that it refers to. (I am
using the word "closure" in a
different sense than in my earlier
post.)
At this point we know that all the
memory still marked is allocated
memory which cannot be reached by any
path from any in-scope variable. All
of those objects are instructed to
tear themselves down, which destroys
any circular references.
The main purpose of garbage collection is to allow the programmer not to worry about memory management of the objects they create and use, though of course there's no avoiding it sometimes - it is always beneficial to have at least a rough idea of how garbage collection works.
Historical note: an earlier revision of the answer had an incorrect reference to the delete
operator. In JavaScript the delete
operator removes a property from an object, and is wholly different to delete
in C/C++.
Best Answer
Ada was designed with military applications in mind. One of the big priorities in its design was determinism. i.e. one wanted an Ada program to consistently perform exactly the same way every time, in any environment, under all operating systems... that kinda thing.
A garbage collector turns one application into two, working against one another. Java programs develop hiccups at random intervals when the GC decides to go to work, and if it's too slow about it there's a chance that an application will run out of heap sometimes and not others.
Simplified: A garbage collector introduces some variability into a program that the designers didn't want. You make a mess - you clean it up! Same code, same behavior every time.
Not that Ada became a raging worldwide success, mind you.