Can somebody please explain to me why char arrays are a special case of arrays?

(when is this useful?)

Saaa wrote:
> Can somebody please explain to me why char arrays are a special case of arrays?
> 
> (when is this useful?)
> 
> 

I don't understand what you mean with "special case". Character arrays (a.k.a. strings) are arrays just like the rest of 'em :)

The only difference is that they have an additional literal constructor in the form of "foo".

 --downs

I meant why are they read only?

> I don't understand what you mean with "special case". Character arrays (a.k.a. strings) are arrays just like the rest of 'em :)
>
> The only difference is that they have an additional literal constructor in the form of "foo".
Where can I read about this?

>
> --downs

Saaa wrote:
> I meant why are they read only?
> 
>> I don't understand what you mean with "special case". Character arrays (a.k.a. strings) are arrays just like the rest of 'em :)
>>
>> The only difference is that they have an additional literal constructor in the form of "foo".
> Where can I read about this?
> 

http://digitalmars.com/d/1.0/arrays.html#strings

 --downs

downs wrote:
> Saaa wrote:
>> Can somebody please explain to me why char arrays are a special case of arrays?
>>
>> (when is this useful?) 
>>
>>
> 
> I don't understand what you mean with "special case". Character arrays (a.k.a. strings) are arrays just like the rest of 'em :)
> 
> The only difference is that they have an additional literal constructor in the form of "foo".
> 
>  --downs

That plus there is special casing in the compiler to support
   foreach(dchar x; some_string) {...}

--bb

I'm sorry about the late reply..

I read it, but still don't really know what you mean additional literal constructor.

But what I really meant was this:
String literals are immutable (read only).

Why is this? (I expect there to be a nice reason for it, I just down't know it :)


>> I meant why are they read only?
>>
>>> I don't understand what you mean with "special case". Character arrays
>>> (a.k.a. strings) are arrays just like the rest of 'em :)
>>>
>>> The only difference is that they have an additional literal constructor
>>> in
>>> the form of "foo".
>> Where can I read about this?
>>
>
> http://digitalmars.com/d/1.0/arrays.html#strings
>
> --downs

Saaa:
>Why is this? (I expect there to be a nice reason for it, I just down't know it :)<

That's an interesting question. Now and then I too feel the need of mutable stings, to change their chars, etc, but here Josh Block and the famous Sedgewick explain why immutables are often good:
http://www.cs.princeton.edu/introcs/33design/

<<
An immutable data type is a data type such that the value of an object never changes once constructed. Examples: Complex and String. When you pass a String to a method, you don't have to worry about that method changing the sequence of characters in the String. On the other hand, when you pass an array to a method, the method is free to change the elements of the array.

Immutable data types have numerous advantages. they are easier to use, harder to misuse, easier to debug code that uses immutable types, easier to guarantee that the class variables remain in a consistent state (since they never change after construction), no need for copy constructor, are thread-safe, work well as keys in symbol table, don't need to be defensively copied when used as an instance variable in another class. Disadvantage: separate object for each value.
Josh Block, a Java API architect, advises that "Classes should be immutable unless there's a very good reason to make them mutable....If a class cannot be made immutable, you should still limit its mutability as much as possible."
>>

Something more:
- Immutable data works well with multiprocessing
- it's common in functional style programming allowing more pure functions
- the GC can manage immutable strings/objects in an efficient enough way.

Bye,
bearophile

Thanks, so the common use of strings is such that it is best to make the
default setting 'immutable'.
Then, how about adding the .access property to arrays? (or all types :)
With strings default .access as read only?


>>Why is this? (I expect there to be a nice reason for it, I just down't know it :)<
>
> That's an interesting question. Now and then I too feel the need of mutable stings, to change their chars, etc, but here Josh Block and the famous Sedgewick explain why immutables are often good: http://www.cs.princeton.edu/introcs/33design/
>
> <<
> An immutable data type is a data type such that the value of an object
> never changes once constructed. Examples: Complex and String. When you
> pass a String to a method, you don't have to worry about that method
> changing the sequence of characters in the String. On the other hand, when
> you pass an array to a method, the method is free to change the elements
> of the array.
>
> Immutable data types have numerous advantages. they are easier to use,
> harder to misuse, easier to debug code that uses immutable types, easier
> to guarantee that the class variables remain in a consistent state (since
> they never change after construction), no need for copy constructor, are
> thread-safe, work well as keys in symbol table, don't need to be
> defensively copied when used as an instance variable in another class.
> Disadvantage: separate object for each value.
> Josh Block, a Java API architect, advises that "Classes should be
> immutable unless there's a very good reason to make them mutable....If a
> class cannot be made immutable, you should still limit its mutability as
> much as possible."
>>>
>
> Something more:
> - Immutable data works well with multiprocessing
> - it's common in functional style programming allowing more pure functions
> - the GC can manage immutable strings/objects in an efficient enough way.
>
> Bye,
> bearophile

Saaa:

>Then, how about adding the .access property to arrays? (or all types :) With strings default .access as read only?<

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

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.

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).

Bye,
bearophile

bearophile wrote:
> Saaa:
> 
>> Then, how about adding the .access property to arrays? (or all types :) With strings default .access as read only?<
> 
> What's the .access property of arrays in the language you talk about?

Basically runtime const, as far as I can tell. You can fake it with a class easily enough.