Not if the application is big and requirements change often.

It's very clever. It takes into advantage the virtual memory system, and allocates/deallocates memory in blazing speed. In my machine, 100,000 objects are freed in less than a millisecond. With 10 threads allocating 100,000 objects, it takes less than a second to finish the program, and my CPU is not even dual core.

Well, it all depends on the requirements of the software. The new project I am about to do must be written in c++, and the deadlines are very strict. I spend 4 months debugging the previous project (120,000 lines of c++ code), and it still have bugs, so I am not doing the same mistake twice.

And they have the unfortunate "advantage" of tranferring ownership when they are assigned...which means they can't be used in anything but simple stack jobs. I think the purpose of auto_ptr was to have a scoped ptr, but the semantics are not correct.

It depends on the complexity of the program. For small programs, manual memory management is ok. For big complex applications, it's a nightmare. Manual memory management simply does not scale.

Qt is good, but it does not use gc. I am planning to use QObject a lot in the new project (because I need to implement a model-view-controller application), but it's going to be complex, so I am going to hack the Qt sources to use Boehm's gc.

Not really. Premature optimization is the root of most evil in quite a few cases. It's easier to identify hot spots using a profiler than trying to manage a memory problem.

Human resources are much more expensive than machines, so if there is a performance problem due to lazy programming, a good option is to throw more hardware at it.

In current Java implementations, string concatenations within an expression is turned to a printf-style expression using StringBuffer.

You have to remember that in Java, allocation is very cheap: the heap pointer is simply incremented. It's like stack allocation.

In c++, although the Boehm's gc is not as fast as Java's (because it's a conservative gc), performance is good (better in some cases) because many objects can be allocated on the stack.

Boehm's gc is incremental (GC_enable_incremental), and it usually does a very good job.

That's why I am not leaving c++ anytime soon.

I don't know why people keep saying that (I am not saying it for you, as you seem to recognize the advantage of gc in c++). It's not true in c++.

For example, you can allocate your garbage-collected objects on the stack:

File file("temp.txt");

Or you can allocate them on the heap, and use a helper class which does the cleanup. For example:

Temp<File> temp(new File);

In both cases, RAII works beautifully.

It's too bad that other languages don't have stack allocation.

If you use another library which globally overrides new and delete, then you are out of lack. MFC does that, and it's a pain in the a$$ (and a major source of memory management problems).

One stupid design decision in c++ is that global new and delete operations can not be part of a namespace...it does not allow to put a bunch of classes in a namespace, then declare new and delete once for all of the namespace.

Another stupid decision in c++ is that new and delete operators don't have access to the type of the allocated object, so it's not possible to have a base class with a garbage-collected new and delete that is not polymorphic.

Despite all this, give me c++ with gc anyday over Java and the alternatives. Templates and stack allocation overshadow any disadvantages.

Well, it's not that simple.

For example, take QValidator objects. You insert them into QLineEdit objects like this:

The above code just introduced a memory leak!

The correct way to do it is:

If you don't pass the owner QObject in the constructor, the validator object will simply never be deleted.

But what if you want to set a new validator to the line edit? You do the following:

But you introduced another memory leak! the previous validator will be there, waiting to be deleted, but it will never be deleted, and even worse, you can't have a pointer to it (unless you traverse the children objects of line edit and find it and delete it)!

Another example is QPopup and QPushButton:

The above again introduces a memory leak, because the popup menu will never be deleted.

Say now that you make the popup a child of the dialog it appears into:

Now the menu will be destroyed when the dialog is destroyed.

Suppose now 3 months pass and another member of your time comes along and decides to reuse the popup menu. He does something like this:

Guess what: we don't have a memory leak, but we have a DANGLING POINTER! which is even more dangerous.

Suppose the user opens 'dialog1' and 'dialog2', then closes 'dialog1'. The popup menu will be destroyed, but nothing will happen. The user will not see it if the memory block previously occupied by 'popup' is not reused in anything else. The user might even use the popup menu as it is, even if the popup menu will have been deleted!

Suppose that another object takes over the memory block occupied the popup menu. The object is 'Account', and its vtable has a function 'deleteAccount' at offset N.

As the user uses the popup menu of 'dialog2', an account is deleted! Because the function 'deleteAccount' was invoked instead of 'close()' or something else the menu was supposed to do!

You see, it's not that simple. The only viable solution for big complex projects with lots of developers is garbage collection.

Java is wonderful, with one minor problem; the language is WAY to verbose for my taste. Java follows the "language designer knows best, so lets shackle the programmer" methodology (for example, no operator overloading is allowed. While this is okay, it just adds a lot of clutter when you actually want to overload an operator (not when you are doing funky "lets make + behave like *" crap, but when you are writing, say, a complex number class...) Checked exceptions are another annoying design problem; far to often I see programmers wrapping the checked exception in RuntimeException to get around it. Not that I recommend doing this, it is just way to often I find myself having to just pass on checked exceptions because I cannot do anything about it (and after a while, I get kinda tired of find, for example, that an interface won't let me throw an exception of a particular type, or other garbage)) instead of the "programmer knows best." Look, if I as a programmer actually want to overload an operator, just get out of my way and let me do it. In other words, the signal to noise ratio in a lot of java code I read seems to be annoyingly high for my taste.

Agreed. Although, with proper encapsulation, memory management scales much further than trying to manage it all by hand (assuming everybody knows who should own the memory to an item, which can be a large assumption at times...).

Java is hardly verbose. I'm sure you can show me some contrived examples and call it proof that Java is verbose. In the real world, a lot less code does a lot more work with a lot less bugs when compared to equivalent C++ projects. You have to realise that Java is an improvement on C++, not the other way around. There are very good reasons it excludes a lot of C++ features. And if you really must use operator overloading, mix it with a bit of Groovy, which overloads operators in a much more readable way than C++.

That's why c++ with garbage collection is better than Java! :-)

EDIT:

According to Hans Boehm, his gc allocates blocks of the same size from the same page, so finding blocks is as simple as dividing the pointer's address (the page offset part, actually) with the block size for that page. It's very very fast, I would dare say faster than manual allocation.

EDIT2:

The D programming language also uses Boehm's gc.