quote:
Originally posted by ShawnZ
quote:
Originally posted by Verte
That's what they should do. But, if you use pointers anywhere, you've got to be very careful with GC. For example, if you pass a pointer variable to a subroutine, and the subroutine uses a temp variable to represent that variable inside, assigns a new object on the heap to the temp variable, and then the temp variable goes out of scope, most GCs will free the object. In cases such as these, you've got to increment the reference counter by hand, which is to say that you're essentially doing manual garbage collection anyway. This is because Garbage collection typically only tracks direct assignments, and where one variable may reference an object indirectly [such as through an array of pointers or references] the GC will not count the [second-order] reference.
IMO, you know when you're done with data, you deal with it.
thats why GC languages don't use pointers, they use references 
A reference is treated much as a pointer internally. Compiled code only contains memory locations, not variable names. References are often more convenient, but they suffer the same problems with GC.
How about overlapping reference arrays, which are often the easiest and most sane way to hold data that needs to be viewed in two different ways? Again, the references aren't distinct but they aren't direct, so when the array they were created in [which was possibly intentionally temporary] passes out of scope, they disappear, and the big array you were holding them in now has a heap of invalid references that will segfault when you try to use them.
was put impeccably into words at DebianDay for me last Saturday, by Knut Yrvin of Trolltech - adults try something once, fail, and then are like "ffs this doesn't work". Children try, fail, and then try again, and succeed - maybe on the second, or even fifth retry. But the thing is that they keep at it and overcome the problems in the end.
-andrewdodd13
