typedef behavior

Simen Kjærås simen.kjaras at gmail.com
Mon Feb 12 08:51:14 UTC 2018


On Sunday, 11 February 2018 at 19:33:23 UTC, Alex wrote:
> On Sunday, 11 February 2018 at 15:18:11 UTC, Simen Kjærås wrote:
>>
>> Basically, Typedef looks like this:
>>
>> struct Typedef(T) {
>>     T _payload;
>>     // Forward method calls, member access, etc, to _payload.
>> }
>>
>> If T looks like this:
>>
>> struct T {
>>     static int[3] arr;
>>     void foo() { arr[0]++; }
>> }
>>
>> How is Typedef supposed to wrap T.foo in such a way that it 
>> uses a different arr depending on whether it's called from the 
>> Typedef or from T?
>>
>> --
>>   Simen
>
> In the same way as it is handled by this:
>
> /// --- code --- ///
>
> void main(){}
>
> static assert(T.arr.ptr != S.arr.ptr);
>
> struct T {
>     static int[3] arr;
>     void foo() { arr[0]++; }
> }
>
> struct S {
>     static int[3] arr;
>     void foo() { arr[0]++; }
> }
>
> /// --- code ends --- ///
>
> I understand that Typedef should be kept simple. But if it 
> defines a type which is recognized as another type in respect 
> to the underlying one, then I should be able to rely on 
> independence of everything, like I would copy/paste the 
> implementation. Or do I misinterpret something?

I agree that'd be nice. Sadly, it's not a reasonable expectation. 
:(

A more extreme example: You have a compiled library, and some .di 
(header) files. In one of those files is this code:

struct S {
     static int[] arr;
     void foo();
}

Now how should Typedef go about making foo() do the right thing? 
Even with compiler support, this is impossible - the source of 
S.foo is simply not available, and it doesn't take the address of 
the static data as a parameter anywhere.

--
   Simen


More information about the Digitalmars-d-learn mailing list