new D2.0 + C++ language

[Rainer Deyke]

Sergey Gromov wrote:
> I think this is an overstatement.  It's only abstract write buffers
> where GC really doesn't work, like std.stream.BufferedFile.  In any
> other resource management case I can think of GC works fine.

OpenGL objects (textures/shader programs/display lists).
SDL surfaces.
Hardware sound buffers.
Mutex locks.
File handles.
Any object with a non-trivial destructor.
Any object that contains or manages one of the above.

Many of the above need to be released in a timely manner. For example,
it is a serious error to free a SDL surface after closing the SDL video
subsystem, and closing the SDL video subsystem is the only way to close
the application window under SDL.  Non-deterministic garbage collection
cannot work.

Others don't strictly need to be released immediately after use, but
should still be released as soon as reasonably possible to prevent
resource hogging.  The GC triggers when the program is low on system
memory, not when the program is low on texture memory.

By my estimate, in my current project (rewritten in C++ after abandoning
D due to its poor resource management), about half of the classes manage
resources (directly or indirectly) that need to be released in a timely
manner.  The other 50% does not need RAII, but also wouldn't benefit
from GC in any area other than performance.


-- 
Rainer Deyke - rainerd at eldwood.com