constness for arrays

[Andrew Fedoniouk]

"xs0" <xs0 at xs0.com> wrote in message news:e9lu7n$2jv0$1 at digitaldaemon.com...
> Andrew Fedoniouk wrote:
>>>> typedef  string char[]
>>>> {
>>>>     disable opAssign;
>>>>     ....
>>>>     char[] tolower() { ..... }
>>>> }
>
> Is there any particular difference from
>
> struct string
> {
>     char[] data;
>
>     char[] tolower() { .... }
> }

difference is in disabled opAssign**, so if you will define
let's say following:

typedef  string char[]
{
    disable opSliceAssign;
    ....
    char[] tolower() { ..... }
}

then you will not be able to compile following:

string s = "something read-only";
s[0..s.length] = '\0'; // compile time error.

>
> ?
>
>> I think that such extended typedef makes sense for other basic types:
>>
>> typedef color uint
>> {
>>     uint red() {  .... }
>>     uint blue() {  .... }
>>     uint green() {  .... }
>> }
>
> Is there any particular difference from
>
> struct color {
>     uint value;
>     uint red() { ... }
>     ...
> }
>
> ?

The difference is that such color is inherently uint so
you can do following:

color c = 0xFF00FF;
c <<= 8;
uint r = c.red();

>
>
>> Also such typedef makes sense for classes too.
>
> I don't get that.. Since you seem to want a new type, what's wrong with 
> deriving?
>

See:

alias NewClass OldClass
{
    void foo() { .... }
}

will not create new VTBL for NewClass.
It is just a syntactic sugar:

Instead of defining and using:

void foo_x( OldClass c ) { ..... }

You can use

NewClass nc = ....;
nc.foo();


>> To avoid vtbl  pollution. Especially actual for templated classes.
>
> Make the methods or class final, then they don't go into vtbl (or at least 
> shouldn't).
>
>

All classes in D has VTBL by definition as far as I remember.

Andrew Fedoniouk.
http://terrainformatica.com