Memory allocation in D (noob question)

[Sean Kelly]

Regan Heath wrote:
> Steven Schveighoffer wrote:
>> "Regan Heath" wrote
>>> Both variables above are references to the same data.  You're using 
>>> one variable to change that data, therefore the other variable which 
>>> still refers to the same data, sees the changes.
>>>
>>> If the concatenation operation had to reallocate the memory it would 
>>> produce a copy, and you wouldn't see the changes.
>>>
>>> So, this behaviour is non deterministic, however...
>>
>> The problem is that invariant data is changing.  This is a no-no for pure
>> functions which Walter has planned.  If invariant data can change 
>> without violating the rules of the spec, then the compiler 
>> implementation or design is flawed.  I think the design is what is 
>> flawed.
> 
> That is another issue which I didn't even address.
> 
> Assuming 'string' means 'invariant(char)' and assuming that means the 
> char values cannot change (I say assuming because I haven't had the 
> chance to really internalise the new const yet) then I reckon the 
> implementation of invariant is simply broken/buggy.

I don't know that it's broken so much as potentially misleading.  That 
example never actually changed any of the data in the string, it simply 
appended additional data to the string.  Thus invariance of the data was 
preserved.

>> Third, I have not seen this T[new] operator described anywhere, but I 
>> am concerned that D 1.0 will not be updated.  This leaves all coders 
>> who are not ready to switch to D 2 at risk.  But from the inferred 
>> behavior of T[new], I'm expecting that this will probably fix the 
>> problem.
> 
> Aside from the apparent invariant bug the only case which causes me a 
> slight worry is the case involving a struct.  The only solution I can 
> imagine would be to somehow determine the memory was originally 
> allocated to a 'struct' and therefore reallocation for an 'array' must 
> cause a copy.
> 
> I'm not sure what information the GC keeps on allocated blocks, I 
> believe there is a pointers/nopointers flag and that could form the 
> basis of a fairly crude test perhaps (as struct contains pointers and 
> char[] does not);

That's pretty much it.  And if the GC were to retain additional type 
info it would be tailored to finding pointers for collection purposes 
rather than determining whether one section of a block is a static array 
or an int.

> Even if nothing can be done to detect this case I'm not sure it's a huge 
> issue, after all it only affects people using static arrays as the first 
> member of a struct which they take a slice of and then modify 
> (concatenate) without performing "copy on write" - which is a no no in D 
> anyway.

Right.


Sean