> What's the .access property of arrays in the language you talk about?

It was a suggestion :)

>
> If you want to try the D language, you may want to use the 1.x series instead of the 2.x that is alpha and has immutable strings.

Didn't they both have immutable strings?
I'm more in search of a way to make char[] not immutable anymore, for most
things I do its only a hassle.

>
> Immutable things (like strings) are useful as AA keys too. In D 1.x (and Ruvy too, maybe) you can use a string as key, but if you later change that string its hash function isn't automatically recomputed, this leads to chaos. In Python you have both mutable and immutable arrays (called list and tuple), strings are immutable, but with the standard module "array" you can use mutable "strings" too. Python AAs called dict accept only their immutable versions to avoid those bugs (and inside tuples you have to put immutables).

Sounds sound to me. This was what I suggested, use a .access property and only accept the 'read-only' for things like that.

Saaa wrote:
> Didn't they both have immutable strings?
> I'm more in search of a way to make char[] not immutable anymore, for most things I do its only a hassle.

On UNIX systems, string literals are stored in the code segment. Thus, modifying them will cause a segfault. In D 1.0, the compiler will let you modify it, but the OS won't. In D 2.0, this rule is enforced by the compiler. Even on Windows, modifying string literals is probably a bad idea.

To allow a string literal to be modified, copy it onto the heap with a .dup .

> On UNIX systems, string literals are stored in the code segment.
If you load a file into a char[][], will the file be stored in the code
segment?
Wouldn't you normally want to edit it after loading?

But shouldn't there be an way (per variable) to force the compiler to not store it like that?

> Thus, modifying them will cause a segfault. In D 1.0, the compiler will let you modify it, but the OS won't. In D 2.0, this rule is enforced by the compiler. Even on Windows, modifying string literals is probably a bad idea.
>
> To allow a string literal to be modified, copy it onto the heap with a .dup .

I know this, although it just says it creates a dynamic array. How do you know that the .dup dynamic array is not read-only.

Saaa:

> If you load a file into a char[][], will the file be stored in the code segment?

Nope.


> But shouldn't there be an way (per variable) to force the compiler to not store it like that?

In practice, there is. In D 1.x string literals are, dynamic ones aren't.


> I know this, although it just says it creates a dynamic array. How do you know that the .dup dynamic array is not read-only.

In D.1.x dyn arrays are mutable.

Bye,
bearophile

from the 1.0 documentation:char[] str;
char[] str1 = "abc";
str[0] = 'b';        // error, "abc" is read only, may crash Is this example
correct?
> Saaa:
>
>> If you load a file into a char[][], will the file be stored in the code segment?
>
> Nope.
>
>
>> But shouldn't there be an way (per variable) to force the compiler to not
>> store it like that?
>
> In practice, there is. In D 1.x string literals are, dynamic ones aren't.
>
>
>> I know this, although it just says it creates a dynamic array. How do you know that the .dup dynamic array is not read-only.
>
> In D.1.x dyn arrays are mutable.
>
> Bye,
> bearophile

from the 1.0 documentation:

char[] str;
char[] str1 = "abc";
str[0] = 'b';        // error, "abc" is read only, may crash

Is this example correct?

Saaa wrote:
>> On UNIX systems, string literals are stored in the code segment.
> If you load a file into a char[][], will the file be stored in the code
> segment?
> Wouldn't you normally want to edit it after loading?
> 
	No, but then it's not a string *literal*

> But shouldn't there be an way (per variable) to force the compiler to not store it like that?
> 
	There is in D 1.0:

char[] foo = "abc";     // Store it in the code segment char[] bar = "abc".dup; // Store it on the heap

>> Thus, modifying them will cause a segfault. In D 1.0, the compiler will let you modify it, but the OS won't. In D 2.0, this rule is enforced by the compiler. Even on Windows, modifying string literals is probably a bad idea.
>>
>> To allow a string literal to be modified, copy it onto the heap with a .dup .
> 
> I know this, although it just says it creates a dynamic array. How do you know that the .dup dynamic array is not read-only.
> 
	Because by definition a *dynamic* whatever can be modified.

		Jerome
- --
+------------------------- Jerome M. BERGER ---------------------+
|    mailto:jeberger@free.fr      | ICQ:    238062172            |
|    http://jeberger.free.fr/     | Jabber: jeberger@jabber.fr   |
+---------------------------------+------------------------------+

Saaa wrote:
> from the 1.0 documentation:
> 
> char[] str;
> char[] str1 = "abc";
> str[0] = 'b';        // error, "abc" is read only, may crash
> 
> Is this example correct?
> 
> 

Yes, because the "abc" is a string literal, that is to say it's written in the code itself. If str1 was loaded from an outside source, such as a file, user input, etc., then you could modify it without issue.

For string LITERALS (a string literal is one you write in the code itself, usually encased in double-quotes), modifying them without calling .dup on them is bad. For other strings, it's perfectly okay.

OK, now I know what I didn't get

Robert Frazier:
LITERALS (a string literal is one you write in the code
itself, usually encased in double-quotes),

>>> On UNIX systems, string literals are stored in the code segment.
>> If you load a file into a char[][], will the file be stored in the code
>> segment?
>> Wouldn't you normally want to edit it after loading?
>>
> No, but then it's not a string *literal*
I get it now :)

>
>> But shouldn't there be an way (per variable) to force the compiler to not
>> store it like that?
>>
> There is in D 1.0:
>
> char[] foo = "abc";     // Store it in the code segment char[] bar = "abc".dup; // Store it on the heap
Good to know.

>
>>> Thus, modifying them will cause a segfault. In D 1.0, the compiler will
>>> let you modify it, but the OS won't. In D 2.0, this rule is enforced by
>>> the compiler. Even on Windows, modifying string literals is probably a
>>> bad
>>> idea.
>>>
>>> To allow a string literal to be modified, copy it onto the heap with a .dup .
>>
>> I know this, although it just says it creates a dynamic array. How do you know that the .dup dynamic array is not read-only.
>>
> Because by definition a *dynamic* whatever can be modified.

I finally see what a string literal means, but this code still bothers me. What does changing a dynamic char[] (str) have to do with the string literal in str1

>> from the 1.0 documentation:
>>
>> char[] str;
>> char[] str1 = "abc";
>> str[0] = 'b';        // error, "abc" is read only, may crash
>>
>> Is this example correct?
>>
>>
>
> Yes, because the "abc" is a string literal, that is to say it's written in the code itself. If str1 was loaded from an outside source, such as a file, user input, etc., then you could modify it without issue.
>
> For string LITERALS (a string literal is one you write in the code itself, usually encased in double-quotes), modifying them without calling .dup on them is bad. For other strings, it's perfectly okay.