new D2.0 + C++ language

[Sergey Gromov]

Sat, 21 Mar 2009 20:16:07 -0600, Rainer Deyke wrote:

> 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.

Thanks for the explanation, it really helps to keep this picture in
mind.