Simen kjaeraas wrote:
> Ivo Kasiuk wrote:
>
> > Ok, that makes sense. So the deallocators really should not get called
> > in this case. But why are the destructors not invoked when the GC
> > finalizes the objects?
>
> For S1 and S2, this is a known bug - destructors of structs on the heap
> do
Ivo Kasiuk Wrote:
>
> - Is there any way the regular finalization sequence (i.e. including
> automatic invoking of the destructors) can be run for an object that
> uses non-GC memory?
It should happen when delete is called. Here's the code executed for delete:
http://dsource.org/projects/drunti
> > Ok, that makes sense. So the deallocators really should not get called
> > in this case. But why are the destructors not invoked when the GC
> > finalizes the objects?
>
> For S1 and S2, this is a known bug - destructors of structs on the heap
> don't get called.
Ah, I see. You mean #2834. Th
> >> > Exploring the example a bit further:
> >> > If C's malloc is used instead of GC.malloc then the deallocators also
> >> > are not called and the program runs out of memory. How are the objects
> >> > supposed to get finalized in this case - do I have to use the delete
> >> > keyword explicit
Ivo Kasiuk wrote:
> Exploring the example a bit further:
> If C's malloc is used instead of GC.malloc then the deallocators also
> are not called and the program runs out of memory. How are the objects
> supposed to get finalized in this case - do I have to use the delete
> keyword explicitly?
> > Exploring the example a bit further:
> > If C's malloc is used instead of GC.malloc then the deallocators also
> > are not called and the program runs out of memory. How are the objects
> > supposed to get finalized in this case - do I have to use the delete
> > keyword explicitly?
>
> If you
Ivo Kasiuk wrote:
Ok, that makes sense. So the deallocators really should not get called
in this case. But why are the destructors not invoked when the GC
finalizes the objects?
For S1 and S2, this is a known bug - destructors of structs on the heap
don't get called.
As for C1, I have no ide
> An interesting case is when using C's malloc for C1 and using the scope
> attribute for c1:
>
> class C1 {
> ubyte[1_000_000] buf;
> new(size_t size) {
> void* ptr = std.c.stdlib.malloc(size);
> if (ptr is null)
> throw new OutOfMemoryError(__FILE__, __LINE__);
> writefln("
Am Samstag, den 18.09.2010, 10:08 -0400 schrieb Sean Kelly:
> Ivo Kasiuk Wrote:
>
> > Hi,
> >
> > to improve my understanding of the GC and when/how
> > allocators/deallocators and constructors/destructors get called, I wrote
> > a little test program. And now I understand even less than before..
Ivo Kasiuk Wrote:
> Hi,
>
> to improve my understanding of the GC and when/how
> allocators/deallocators and constructors/destructors get called, I wrote
> a little test program. And now I understand even less than before...
...
> Running this with DMD 2.049, I observed the following:
>
> - S1(i
Hi,
to improve my understanding of the GC and when/how
allocators/deallocators and constructors/destructors get called, I wrote
a little test program. And now I understand even less than before...
Here is the program:
import core.memory;
import std.stdio;
str
11 matches
Mail list logo
