Memory allocation in D (noob question)

Steven Schveighoffer schveiguy at yahoo.com
Tue Dec 4 19:14:37 PST 2007


"Sean Kelly" wrote
> Steven Schveighoffer wrote:
>> "Steven Schveighoffer" wrote
>>> Another reason why this is seems to be a bug and NOT a feature:
>>>
>>>        string ab = "ab".idup;
>>>        string a = ab[0..1];
>>>        a ~= "c";
>>>        writefln("ab = ",ab); // also outputs "ac"
>>>
>>> This changes an invariant string without compiler complaint!
>>
>> more bugs :)
>
> This is expected behavior.

Behavior by design, perhaps.  Expected, I should hope not.  I would never 
expect to be able to have one variable overwrite another without obvious 
casting.  And why should it be 'expected behavior' for the GC to assume that 
because an array is at the beginning of a memory block, it is free to use 
any memory in that block?  I think I've proven that there are cases where it 
should not assume that.

I'm not saying there is a bug in the compiler implementation, or that the 
docs need to be changed to reflect the compiler behavior.  I'm saying the 
design here is flat out wrong, and needs to be reflected in the compiler. 
My recommendation would be to make the ~= behave exactly as the spec says, 
that it always makes a copy of it's arguments.  If you need buffer-like 
behavior for performance, write a new type.

Isn't one of Walter's goal to prevent silent runtime errors?  IMO, memory 
corruption errors are the worst kind of silent errors.

-Steve 





More information about the Digitalmars-d mailing list