choi heejo wrote:
> hi there, please read this code:
>
>
> import std.stdio;
>
>
> struct test(T)
> {
> alias typeof(*this) type;
> T a;
> }
>
>
>
>
> void main()
> {
> test!(int).type t;
>
> t.a = 123;
>
> writeln(t.a);
> }
>
>
> I guessed it would work. but the compiler said:
>
>
>
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 - dest
> On Sat, 09 Oct 2010 15:51:37 -0400, Ivo Kasiuk wrote:
>
> > Hi!
> >
> > In my D programs I am having problems with objects not getting finalised
> > although there is no reference anymore. It turned out that this is
> > caused by integers which happen to h
> > > ~snip
> > > >
> > > > This writes:
> > > > new uint
> > > > no reference
> > > > == reference, f7490e20, f7490e10, f7490df0,
> > f74
> > > > 90dd0
> > > > AA
> > > > struct
> > > > uint
> > > > reference
> > ...
> > > > Thanks,
> > > > Ivo
> >
> ~snip
> >
> > This writes:
> > new uint
> > no reference
> > == reference, f7490e20, f7490e10, f7490df0, f74
> > 90dd0
> > AA
> > struct
> > uint
> > reference
...
> > Thanks,
> > Ivo
>
> In D1:
...
> Writes:
> no reference
> == reference,
Hi!
In my D programs I am having problems with objects not getting finalised
although there is no reference anymore. It turned out that this is
caused by integers which happen to have values corresponding to pointers
into the heap. So I wrote a test program to check the GC behaviour
concerning int
> > 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
> > 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
> 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 no
Am Samstag, den 18.09.2010, 02:15 -0700 schrieb Jonathan M Davis:
> Okay, if I try and compile the following program.
>
> struct S
> {
> @property S save() const
> {
> return this;
> }
>
> int[] _val;
> }
>
> void main()
> {
> }
>
Actually, wouldn't it be much more simp
and why the deallocators and the
destructors (apart from ~C2) do not get called. If the memory for the
objects gets freed, as is apparently the case, then why are there no
destructor and deallocator calls for these objects?
Thanks
Ivo Kasiuk
13 matches
Mail list logo
