struct inheritance
Regan Heath
regan at netmail.co.nz
Fri Aug 31 02:10:57 PDT 2007
kris wrote:
> Regan Heath wrote:
>> kris wrote:
>>> Bill Baxter wrote:
>>>> Robert Fraser wrote:
>>>>> Bill Baxter Wrote:
>>>>>
>>>>>> Let us all turn our copies of WalterAndrei.pdf to page 40 where
>>>>>> yea verily it doth say:
>>>>>>
>>>>>> struct M { int a; }
>>>>>> struct S {
>>>>>> M m;
>>>>>> alias m this;
>>>>>> int b;
>>>>>> }
>>>>>>
>>>>>> Why not just allow mixin to do this?
>>>>>>
>>>>>> struct M { int a; }
>>>>>> struct S {
>>>>>> mixin M;
>>>>>> int b;
>>>>>> }
>>>>>>
>>>>>> That's basically the way it's done now except now it would be more
>>>>>> like:
>>>>>> template MMixin() { int a; }
>>>>>> struct M { mixin M; }
>>>>>> struct S { mixin M; int b; }
>>>>>>
>>>>>> Just let us treat a struct like a zero arg template for mixin
>>>>>> purposes.
>>>>>>
>>>>>> --bb
>>>>>
>>>>> It amounts to the same thing, so it just depends on which syntax
>>>>> you prefer. Personally, I like...
>>>>>
>>>>> struct S : M { int b; }
>>>>>
>>>>> ... meaning S is non-polymorphically inherited from M. I guess the
>>>>> argument against taht syntax was that it would be confusing for
>>>>> people from a C++ background who assume polymorphic inheritance for
>>>>> structs.
>>>>>
>>>>> Anyways, it's up to Walter to decide on the syntax, and he says
>>>>> "alias this".
>>>>
>>>> I did just think of one issue which is that constructors/opCalls for
>>>> M would be weird. S needs to decide how to initialize the M part,
>>>> which would be difficult if M's constructors are just mixed in
>>>> directly.
>>>>
>>>> I guess from a compiler-writers perspective "alias this" is more
>>>> like what actually happens when you inherit in typical C++ fashion.
>>>> In that case I guess I'd prefer 'import'
>>>>
>>>> struct M { int a; }
>>>> struct S {
>>>> import M;
>>>> int b;
>>>> }
>>>>
>>>> then you can specify when you need to access the M parts just like
>>>> you do in C++ by M.member.
>>>>
>>>> I'd even prefer "alias m .;" to "alias m this;". It just seems
>>>> wrong and goes against the nice happy view that 'this' is just an
>>>> implicitly defined pointer member.
>>>>
>>>> --bb
>>>
>>> Perhaps a bigger problem is this:
>>>
>>> # struct M { int a; }
>>> # struct S {
>>> # int b;
>>> # import M;
>>> # }
>>>
>>> Now, S is no longer derived from M. Hence, it would seem the right
>>> way to do this is to take it out of the hands of the developer and do
>>> something akin to
>>>
>>> # struct S : M
>>>
>>> as had been suggested previously. Sure, that particular syntax may
>>> mean something else to some C++ folks, but at least the intent is
>>> clear and the /outcome/ is consistent.
>>
>> When you say "derived from M" are you referring to the ordering/layout
>> of M matching that of the start of S (new fields of S therefore
>> existing in the part of S which is larger than M).
>>
>> I'm not sure "derived" is the right term to use, we don't want to
>> confuse it with class derivation, perhaps saying "S is based on M" is
>> better? /You say potatoes I say ../
>>
>> As one of the main reasons/uses for structs is to define a specific
>> layout in memory, perhaps the main reason for Walters syntax is to
>> make it possible to define that layout however required.
>>
>> I think there are cases where they should match, and you should be
>> able to cast from S to M (albeit with slicing and woe to the developer
>> who tries to cast an array of S to M - but perhaps the cast operator
>> can handle this case?). In this case S is based on M.
>>
>> I think there are also cases where you need to specify a different
>> layout and in this case S would not be based on M.
>>
>> Regan
>
>
> Briefy:
>
> ok, S /extends/ M :)
<g>
> The ordering becomes an issue when you have a pointer to S, and wish to
> use it as a pointer to an M. That's why, in C, the super-struct is
> manually inserted as the first struct member. If you manually insert the
> super-struct as the second or third member then, obviously, your pointer
> is not convertible
Yep, exactly. In this case you definately want S to extend M and in
this exact manner. However, I wonder if there are cases where you want
a different layout in memory. If so, the syntax must support both options.
Regan
More information about the Digitalmars-d
mailing list