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