Thread overview
reference error?
May 31, 2005
Ant^2i
May 31, 2005
Ben Hinkle
May 31, 2005
Ant^2i
May 31, 2005
Ben Hinkle
May 31, 2005
Ben Hinkle
May 31, 2005
I am not quite sure about how references should work. But shouldn't below example print any ACCESS VIOLATION error?

class Test
{
Test next;
int v;
}

void main ()
{
Test t0=new Test();
Test t1=new Test();

t0.next=t1;

delete t1;

// ACCESS VIOLATION ?
t0.next.v=34; // there shouldn't be t0.next anymore?

std.process.system("pause");
}


May 31, 2005
"Ant^2i" <Ant^2i_member@pathlink.com> wrote in message news:d7i517$26in$1@digitaldaemon.com...
>I am not quite sure about how references should work. But shouldn't below
> example print any ACCESS VIOLATION error?
>
> class Test
> {
> Test next;
> int v;
> }
>
> void main ()
> {
> Test t0=new Test();
> Test t1=new Test();
>
> t0.next=t1;
>
> delete t1;
>
> // ACCESS VIOLATION ?
> t0.next.v=34; // there shouldn't be t0.next anymore?
>
> std.process.system("pause");
> }

The "delete t1" statement invalidates all references to the object referred to by t1. The assignment "t0.next = t1" makes t0.next refers to the same object that t1 refers to so when you delete t1 you also "delete" t0.next. Think of it this way: references are like implicit pointers and "delete" is like calling free - all the pointers to the memory are invalidated.


May 31, 2005
In article <d7i7vb$29b4$1@digitaldaemon.com>, Ben Hinkle says...
>
>
>"Ant^2i" <Ant^2i_member@pathlink.com> wrote in message news:d7i517$26in$1@digitaldaemon.com...
>>I am not quite sure about how references should work. But shouldn't below
>> example print any ACCESS VIOLATION error?
>>
>> class Test
>> {
>> Test next;
>> int v;
>> }
>>
>> void main ()
>> {
>> Test t0=new Test();
>> Test t1=new Test();
>>
>> t0.next=t1;
>>
>> delete t1;
>>
>> // ACCESS VIOLATION ?
>> t0.next.v=34; // there shouldn't be t0.next anymore?
>>
>> std.process.system("pause");
>> }
>
>The "delete t1" statement invalidates all references to the object referred to by t1. The assignment "t0.next = t1" makes t0.next refers to the same object that t1 refers to so when you delete t1 you also "delete" t0.next. Think of it this way: references are like implicit pointers and "delete" is like calling free - all the pointers to the memory are invalidated.
>
>
Hmm, maybe I told my problem a bit incorrectly. My english is so bad...
Anyway, when running that code, it doesn't print "access violation"-error at
all.
Doesn't t0.next.v=34; write value to null object without access?


May 31, 2005
> Hmm, maybe I told my problem a bit incorrectly. My english is so bad...
> Anyway, when running that code, it doesn't print "access violation"-error
> at
> all.
> Doesn't t0.next.v=34; write value to null object without access?

I think it is not defined if it gives an access-violation or not. The
statement t0.next.v = 34 writes to an invalid object - not a "null object".
For example the equivalent situation for pointers would be
import std.c.stdlib;
int main() {
    int* x = cast(int*)malloc(int.sizeof);
    int* y = x;
    *x = 34;
    free(y);
    *x = 34;
    return 0;
}
After you call free(y) the pointer in y and x are dangling pointers.
Similarly after delete(t1) the reference in t0.next is a "dangling
reference". That's one reason not to call delete() explicitly unless you
know no other references to that object exist.


May 31, 2005
"Ben Hinkle" <bhinkle@mathworks.com> wrote in message news:d7ig75$2hcl$1@digitaldaemon.com...
>> Hmm, maybe I told my problem a bit incorrectly. My english is so bad...
> After you call free(y) the pointer in y and x are dangling pointers. Similarly after delete(t1) the reference in t0.next is a "dangling reference". That's one reason not to call delete() explicitly unless you know no other references to that object exist.

Is that how it works?  I figured the GC wouldn't clean up t1 because there is still a reference to it in t0.next, even though you deleted t1.  Or maybe it just hasn't been cleaned up yet..


May 31, 2005
"Jarrett Billingsley" <kb3ctd2@yahoo.com> wrote in message news:d7iod5$2pel$1@digitaldaemon.com...
> "Ben Hinkle" <bhinkle@mathworks.com> wrote in message news:d7ig75$2hcl$1@digitaldaemon.com...
>>> Hmm, maybe I told my problem a bit incorrectly. My english is so bad...
>> After you call free(y) the pointer in y and x are dangling pointers. Similarly after delete(t1) the reference in t0.next is a "dangling reference". That's one reason not to call delete() explicitly unless you know no other references to that object exist.
>
> Is that how it works?  I figured the GC wouldn't clean up t1 because there is still a reference to it in t0.next, even though you deleted t1.  Or maybe it just hasn't been cleaned up yet..

from http://www.digitalmars.com/d/class.html#destructors
"The program can explicitly inform the garbage collector that an object is
no longer referred to (with the delete expression), and then the garbage
collector calls the destructor immediately, and adds the object's memory to
the free storage."


June 01, 2005
"Ben Hinkle" <ben.hinkle@gmail.com> wrote in message news:d7ipr1$17q$1@digitaldaemon.com...
> from http://www.digitalmars.com/d/class.html#destructors
> "The program can explicitly inform the garbage collector that an object is
> no longer referred to (with the delete expression), and then the garbage
> collector calls the destructor immediately, and adds the object's memory
> to the free storage."

There it is.