http://d.puremagic.com/issues/show_bug.cgi?id=2757
Summary: resource management in a timely manner Product: D Version: 1.041 Platform: PC OS/Version: Windows Status: NEW Keywords: spec Severity: enhancement Priority: P3 Component: DMD AssignedTo: bugzi...@digitalmars.com ReportedBy: nick.barbal...@gmail.com email 23 Mar 2009 from the D.d list. Subject : "Re: new D2.0 + C++ language". 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. --