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