Andrei Alexandrescu wrote: > On 2/27/15 1:09 AM, ted wrote: >> Andrei Alexandrescu wrote: >> >>> http://wiki.dlang.org/DIP74 got to reviewable form. Please destroy and >>> discuss. >>> >>> Thanks, >>> >>> Andrei >> >> Trivial typos: >> >> struct, class, and closure types that have RCO members accommodate calls >> to Release during their destruction. >> s/Release/opRelease/ >> >> Explicit casting to of from void* does not entail a call to opAddRef. >> s/of/or/ >> >> also: s/opReleasecalls/opRelease calls/ >> >> The examples in "Defining a reference counted object with deallocation", >> and "defining a type that owns resources" both define '_refs', and >> manipulate 'refs'. > > Fixed, thanks! > >> This is probably a really stupid question, but how does the 'new' work >> for an RCO. I assume it uses the GC memory allocation system, but must >> mark it as 'not for collection' (or similar), for the GC.free() call to >> work (as used in the examples). > > DIP74 does not prescribe specific allocation techniques. They are left > to the user.
I'm still a bit confused here: the examples in DIP74 showed the freeing of memory via 'GC.free(cast(void*) this);' - so I had assumed that 'Widget a = new Widget' would be the way it was created? (and that automatically uses GC - or is this what I am missing?) I can see how a system that used (for example) malloc/calloc/free would work, I'm just querying the consistency of the examples within DIP74? > > One nice point of the design space would be to use the GC for allocation > and early deallocation, in such a way that the GC is still able to > collect cycles. > >> Probably another silly question: How would the examples work with >> const/immutable (using examples in howtos)? >> e.g. const Widget a = new Widget; >> auto b = a; <-- mutable method Widget.opAddRef is not callable >> using a const object > > This is tricky. I meant to discuss it; for now I planted a TODO. > > > Andrei