Qian Xu wrote:
Denis Koroskin wrote:
...
For example, let's modify CSTR and see what happens:
CSTR[0] = 'J'; // now it is "Jello"
printing e.str and e2.str gives us the following output:
Jello
Jello
...
Hi again,
but there is one thing, I do not understand.
CSTR is a constant. But with "CSTR[0] = 'J'", you can modify a const anyway,
cannot you?
CSTR is a string constant. It's in a data segment of the binary that DMD
creates. However, on Windows, string constants are in a read-write area
of memory, so you can change them; but for efficiency, there is only one
copy of each string constant in the binary.
On Linux, that code would produce a segmentation fault -- there, string
constants are in a read-only text segment. (I believe I heard that the
MinGW compiler on Windows makes string constants read-only, so this may
be compiler specific.)
BTW: Do you know, why D do not use copy-on-write semantic instead of
referencing? IMO, copy-on-write is much performanter.
It makes the compiler a fair bit more complicated. It requires syntax to
create a copy-on-write array versus a by-reference array, or to refer to
a COW array by reference (so if you modify it, aliases to the same array
get modified). And copy-on-write does not give you better performance.
Most of all, nobody's made a compelling case to Walter about this. It's
easy enough to .dup an array if you're about to modify it, though bugs
from accidentally modifying an array in place are rather hard to track.
On the other hand, if you have a reasonable const system, these bugs
turn into compile errors.
--Qian
