[ monarch_dodra wrote ] Well, that's always been the case, and even worst, since in a
dynamic array, destructor are guaranteed to *never* be run.



https://issues.dlang.org/show_bug.cgi?id=2757


Resource Management. A issue that has been discussed since 2009, and still no *GOOD* solution.


Look at these arguements made back then.


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.


The language set up the defaults when these are to run. The programmer has to override the defaults. [Sure this crude, but it deterministic]

[comment by dsimcha inm 2009 ] Come to think of it, as simple and kludgey sounding as it is, this is an incredibly good idea if you have an app that does a lot of sitting around waiting for input, etc. and therefore not allocating memory and you want an easy way to make sure it releases resources in a reasonable amount of time. This belongs in
an FAQ somewhere.

Reply via email to