www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - struct destructors

reply Alexander <aldem+dmars nk7.net> writes:
Are those supposed to be called when struct was allocated on the heap and is
collected by GC?

According to my observations (DMD 2.052 Linux), they are called only when:
- struct is allocated on the stack and goes out of scope;
- explicit delete is called on heap-allocated struct.

/Alexander
May 09 2011
next sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
On May 9, 2011, at 9:21 AM, Alexander wrote:

 Are those supposed to be called when struct was allocated on the heap =

Not currently. I thought I wrote some explanation of why... somewhere, = but I can't find it right now (2834 is the ticket number for this issue, = but my comments aren't in there). Maybe it was just that this will be a = technically difficult problem to solve. I'll do some more searching and = see if I can turn out that comment.=
May 09 2011
parent Alexander <aldem+dmars nk7.net> writes:
On 09.05.2011 19:38, Sean Kelly wrote:

 Not currently.  I thought I wrote some explanation of why...

OK, thanks - I've read the ticket. Though, the problem can be solved relatively simple, IMHO - adding one more pointer to BlkInfo, where address of the finalizer is stored, which will be used only for cases when collected object is not a class. For now, it seems, better to avoid struct destructors at all, or resort to classes. /Alexander
May 09 2011
prev sibling next sibling parent Sean Kelly <sean invisibleduck.org> writes:
On May 9, 2011, at 12:51 PM, Alexander wrote:

 On 09.05.2011 19:38, Sean Kelly wrote:
=20
 Not currently.  I thought I wrote some explanation of why...

OK, thanks - I've read the ticket. Though, the problem can be solved =

address of the finalizer is stored, which will be used only for cases = when collected object is not a class. Well... BlkInfo is generated from a selection of internal sources. = You're right that the GC would need to store a finalizer reference for = structs, but that's just the simple case. It would also need to = finalize structs in dynamic arrays and AA nodes as well (though it's = possible the latter already works, since the AA is now template code). = And of course the finalizer reference would have to be passed to = GC.malloc() or whatever so that portion of the API would change as well. = I originally held off on fixing this because its requirements seemed to = fit nicely with the requirements for precise scanning (ie. passing the = GC some TypeInfo so it can be smarter about how it deals with allocated = memory blocks in general), and I wanted to do both at once. But I have = a feeling that I came up with some other problem regarding struct = finalization, so I want to see if I can find that old email or whatever = to be sure.=
May 09 2011
prev sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 09 May 2011 17:04:49 -0400, Sean Kelly <sean invisibleduck.org>  
wrote:

 On May 9, 2011, at 12:51 PM, Alexander wrote:

 On 09.05.2011 19:38, Sean Kelly wrote:

 Not currently.  I thought I wrote some explanation of why...

OK, thanks - I've read the ticket. Though, the problem can be solved relatively simple, IMHO - adding one more pointer to BlkInfo, where address of the finalizer is stored, which will be used only for cases when collected object is not a class.

Well... BlkInfo is generated from a selection of internal sources. You're right that the GC would need to store a finalizer reference for structs, but that's just the simple case. It would also need to finalize structs in dynamic arrays and AA nodes as well (though it's possible the latter already works, since the AA is now template code). And of course the finalizer reference would have to be passed to GC.malloc() or whatever so that portion of the API would change as well. I originally held off on fixing this because its requirements seemed to fit nicely with the requirements for precise scanning (ie. passing the GC some TypeInfo so it can be smarter about how it deals with allocated memory blocks in general), and I wanted to do both at once. But I have a feeling that I came up with some other problem regarding struct finalization, so I want to see if I can find that old email or whatever to be sure.

A few things here: 1. the reason why a struct is not finalized when allocated on the heap is because a struct does not have a vtable pointer (which is how the GC is able to find the dtor for a class). 2. A struct allocated on the heap is actually transformed by the compiler into an allocation of an array of one struct instance. So essentially there is one problem to solve -- how to finalize an array of structs. 3. AA's are templated, but the templated functions simply forward to the runtime functions. The template allows us to add extra functionality to an AA without modifying the compiler, but everything is very much done by druntime. However, I think we would have the ability to add this without modifying the compiler. -Steve
May 16 2011