Destroying structs (literally)

monarch_dodra via Digitalmars-d digitalmars-d at puremagic.com
Fri Aug 29 11:39:04 PDT 2014


On Friday, 29 August 2014 at 18:12:04 UTC, Orvid King wrote:
> On 8/29/2014 12:41 AM, monarch_dodra wrote:
>> Questions:
>> - Can and will this work for arrays of structs?
>> - When doing manual GC allocations (for whatever reason), how 
>> can we
>> later tell the GC what destructor to call?
>
> Yes, this does work for arrays of structs. Provided that you've 
> passed in the type info for the struct when doing the manual 
> allocation, it should call the destructor without anything 
> extra needing to be done on the user's part.

Hum... by "manual" memory allocation. I meant this:

GC.qalloc(newlen * T.sizeof, blockAttribute!T);

That's what Appender does. Unless I'm mistaken, the Type info is 
not passed here? Furthermore, the Type info *can't* be passed...?

> > These questions combined are really aimed at Appender: I'm
> curious at if
> > and how any changes will have to be made to it.
>
> Appender already uses the type info's destroy, so it shouldn't 
> have any issues, as I already had to account for that.

This is news to me. Appender does not destroy anything. It makes 
no call to delete/destroy/release or whatnot. It simply just 
keeps allocating away.

> > Also question: Will this play nice wit exiting code that
> manually
> > destroys GC allocated structs?
>
> As I mentioned elsewhere, as long as the existing code is 
> calling destroy, and not calling the finalizer directly, then 
> yes, it will play nice, and only call the finalizer once.

OK. Nice. Thanks.

BTW: If Appender is "broken", that's OK (in the sense that it 
won't be any more "broken" than before). I just want as much 
information as possible about what I (we) will need to do to 
update it.

In particular, Appender has an optimization that skips postblit 
to "relocate" when possible. If destructions start happening, 
then we'll need to make sure we first reset to "T.init", or we'll 
risk destroying a non-postblitted copy (which could be 
catastrophic in the case of RC'ed structs).


More information about the Digitalmars-d mailing list