Analysis of Each Use Case

For trash collection - sight issues with trash and reference counted systems [I had a good one recently - can't find it at the moment - bug easy to google for.]

Complexity of Current GC for C++ Design

Type qualifiers vs. modifiers vs. attribute for gc_strict and gc_relaxed - are none of these. We have no experience with such constructs and how they interact with type system.

The new operator has some unspecified magic which allows it to communicate with the type system to know about strict/weak declarations. This information is not available to anyone writing a replacement allocator (which is quite common) and makes it impossible to use an existing application GC allocator (such as sharing an allocator with JavaScript or Managed C++) unless the system provides it.

The proposal breaks conventions for RAII - and we have no experience or guidelines. When should one call delete?

The gc_required and gc_forbidden keywords bifurcate the language.

Suppress and collect must be used for critical areas of performance.

No guidance on how multiple collectors in the same application will interact.

Note that the vast amount of complexity necessary for GC is apparent in the number of keywords and library routines to support it. This is a strong argument that it is of little use for saving bad application - it is just as likely that GC will be misused (if not more so) then memory. Google "unmanaged pointers managed C++" for many examples. Note that as long as we support the C libraries (and C runtime) such issues will always be part of C++.

Outline a Proposal to Address Some Issues

Eliminate gc_required

gc_strict as a type qualifier or attribute

Definition of a operator new() in the presence of GC

Use of gc_strict as part of type to guide and check RAII.

Conclusions

Complex solution to problem for which simple solutions are widely used and will be improved by C++0x leaving us little need.

We have little to no experience with the recommended language features which are to be standardized.