Website message overhaul

[Timon Gehr]

On 11/20/2011 09:40 AM, Paulo Pinto wrote:
> Am 19.11.2011 21:49, schrieb Timon Gehr:
>>>
>>
>> The fact that Nicks example works has no implications for the GC
>> implementation because the two types involved in his reinterpret-casting
>> don't have any indirections.
>>
>> Furthermore:
>>
>> int* a =...;


I meant
int* a = new int;
here, just in case anyone is wondering.

>> int b = cast(int)a;
>> int* c = cast(int*)b;
>> // assert(a == c); // not guaranteed!
>>
>> The language allows the GC to move around heap data.
>> What kind of GC would be impossible to implement?
>
> I am by no means a GC expert, but I was under the impression that D
> could only make use of conservative GC because of the casting tricks.

D's GC could make use of any advanced GC algorithm I am aware of, it 
just has to be implemented (the bottleneck is probably compiler 
support). At the moment, the GC is conservative because the compiler 
provides no runtime information about which pieces of memory are 
pointers/references and which are not

>
> What if Nick's example had inner pointers?
>
> align(1) struct Foo
> {
> int x, y;
> ubyte r, g, b, a;
> char[16] ident;
> uint[100] data;
> Foo* next;
> }
>

That is actually not a problem. Dereferencing an invalid pointer is 
unrelated to GC issues. And if the pointer is always valid, then it does 
not point to GC memory, therefore it can be ignored by the GC.

>
> Is the GC smart enough to know that Foo.next will contain garbage after
> the assignment with cast?

How can it know that it will contain garbage? Not every object in a D 
program is necessarily GC heap allocated. But the GC does not have to 
care anyway, as soon as unsafe casts are in play it is the 
responsibility of the programmer to ensure correctness.

> What about when I later assign a valid value to it?

That works as expected, because the type information is available.