Memory allocation in D (noob question)
Steven Schveighoffer
schveiguy at yahoo.com
Wed Dec 5 06:06:11 PST 2007
"Regan Heath" wrote
> Steven Schveighoffer wrote:
>> "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.
>
> In this post I'm commenting on the example shown above, not the 2nd one
> (which to be honest is much more worrying). I am a bit confused as to
> which example Sean was saying was "expected behaviour".
>
>> 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.
>
> 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.
I have several problems with this concat operator issue.
First, that x ~= y does not effect the same behavior as x = x ~ y. This is
a fundamental flaw in the language in my opinion. any operator of the op=
form is supposed to mean the same as x = x op y. This is consistent
throughout all of D, except in this case.
Second, there is the issue of the spec. The spec clearly states that
concatenation should result in a copy of both sides. Obviously, this isn't
true in all cases. The spec should be changed for both D 1.x and 2.x
IMMEDIATELY to prevent unsuspecting coders from using ~= when what they
really want is just ~.
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.
-Steve
More information about the Digitalmars-d
mailing list