constness for arrays

[xs0]

Andrew Fedoniouk wrote:
> "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.

But you can also not define opSliceAssign in struct string, and get the 
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();

Besides the first line, you can do the same with a struct. And I'd say 
it's good that color and uint are not fully interchangeable, considering 
how they have nothing in common; one is a 32-bit integer, the other is 
more a byte[3] or byte[4], and even then you can't really say that a 
'generic 8-bit integer' and a 'level of red intensity' have much in common..


>>> 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();

Well, if you override a function, it should be virtual. If it didn't 
exist and is final, the compiler should be able to determine it can call 
it directly. If it is not final (meaning you plan to override it in a 
further derived class), it should again be virtual.. So I don't see the 
problem..

Also, why would you want a non-member function to look like it is a 
member function? Just causes confusion..

Finally, bar.foo() isn't really a shorthand for foo(bar), being one 
character longer.. Seems more like syntactic saccharin :)


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

Yup.

xs0