On Fri, 02 May 2014 21:03:15 +0000
monarch_dodra via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> On Friday, 2 May 2014 at 15:06:59 UTC, Andrei Alexandrescu wrote:
> > So now it looks like dynamic arrays also can't contain structs with destructors :o). -- Andrei
>
> Well, that's always been the case, and even worst, since in a dynamic array, destructor are guaranteed to *never* be run. Furthermore, given the "append causes relocation which duplicates", you are almost *guaranteed* to leak your destructors. You just can't keep track of the usage of a "naked" dynamic array.
>
> This usually comes as a great surprise to users in ".learn". It's also the reason why using "File[]" never ends well...

Heck, I probably knew that before, but I had completely forgotten. If you'd asked me yesterday whether struct destructors were run in dynamic arrays, I'd have said yes. And if someone like me doesn't remember that, would you expect the average D programmer to? The current situation is just plain bug-prone.

Honestly, I really think that we need to figure out how to make it so that struct destructors are guaranteed to be run so long as the memory that they're in is collected. Without that, having destructors in structs anywhere other than directly on the stack is pretty much broken.

- Jonathan M Davis

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

I forgot to add these comments by walter at the top of my previous post:


> [walter Bright wrote ] the thing is, GC is a terrible and unreliable method of managing non-memory
resource lifetimes. Destructors for GC objects are not guaranteed to ever run.


> So now it looks like dynamic arrays also can't contain structs with destructors :o). -- Andrei

Nick

On Friday, 2 May 2014 at 21:12:12 UTC, H. S. Teoh via Digitalmars-d wrote:
> On Fri, May 02, 2014 at 09:03:15PM +0000, monarch_dodra via Digitalmars-d wrote:
>> On Friday, 2 May 2014 at 15:06:59 UTC, Andrei Alexandrescu wrote:
>> >So now it looks like dynamic arrays also can't contain structs with
>> >destructors :o). -- Andrei
>> 
>> Well, that's always been the case, and even worst, since in a dynamic
>> array, destructor are guaranteed to *never* be run. Furthermore, given
>> the "append causes relocation which duplicates", you are almost
>> *guaranteed* to leak your destructors. You just can't keep track of
>> the usage of a "naked" dynamic array.
>> 
>> This usually comes as a great surprise to users in ".learn". It's also
>> the reason why using "File[]" never ends well...
>
> This is why I'm unhappy with the way this is going. Current behaviour of
> structs with dtors is already fragile enough, now we're pulling the rug
> out from under classes as well. So that will be yet another case where
> dtors won't work as expected.
>
> I'm getting the feeling that dtors were bolted on as an afterthought,
> and only works properly for a very narrow spectrum of use cases. Rather
> than expand the usable cases, we're proposing to reduce them (by getting
> rid of class dtors). I can't see *this* ending well either. :-(

Unfortunately, the rug they are standing is placed over a gaping hole in the ground, metaphorically speaking, so it never was a very stable situation to begin with. I'm not sure it makes sense to put much effort into increasing the likelihood that destructors are called, when we then _still_ can't guarantee it.

Better to acknowledge that it simply can't work (if that's the case), and try to find a way to avoid these situations. For example, we could statically forbid GC managed objects with destructors (not classes, but _anything_ GC managed). That means that calling new for these types, or allocating a dynamic array of them, will be an error. Of course, an escape hatch needs to be put in place. "isolated" might be a candidate.