Multiple Inheritance of Classes

Christopher Wright dhasenan at gmail.com
Wed Aug 13 04:30:38 PDT 2008


Benji Smith wrote:
> superdan wrote:
>> better put doesn't do multiple inheritance of data. why? simple. d is 
>> a fixed layout language. means that the offset of any data member 
>> within the object is known during compilation. with mi it is 
>> impossible to lay out objects in a fixed layout. unless you do it the 
>> nonsensical way c++ does. at least you can't lay out with 
>> 1-dimensional memory. (i've done vlsi design and sure as shit 2-dim 
>> helps a lot. but a lot more could be done with 3-dim. i remember only 
>> adding two layers was a huge deal.) with mi from n classes you'd need 
>> n-dimensional ram. that's why only simple inheritance is possible with 
>> 1-dimensional ram. if u want fixed layout that is. (now that i got 
>> into it there was a guy who did 2-class inheritance by storing stuff 
>> at positive and negative offsets, thus adding a 2nd dimension.) mi of 
>> interfaces is a good thing and putting an int in an interface does not 
>> make it evil. just makes it impossible to lay out.
> 
> Which begs the question of why D is a fixed layout language. My 
> impression is that, if MI was a high enough priority, the data layout 
> issues could be easily solved (maybe by having the compiler 
> automatically generate the necessary interfaces and mixins, and using a 
> separate data layout for each inheritance permutation).

Accessing members in a fixed-layout class is easy: *(this + offset). And 
the offset is known at compile time, so it's probably one instruction. 
(Granted, the member is probably in cache rather than a register if 
you're doing this, so it'll take more time than that anyway.)

If you don't do that, you need to use some sort of indirection. And you 
have to regenerate the mapping from identifier to offset for each class 
in the hierarchy. This is slower, albeit not incredibly slow, and it's 
more work, and without multiple inheritance, why bother?

Also, casting with some arbitrary layout might mean generating a new 
class, effectively, unless you keep your mapping on the classinfo of the 
object (which costs extra page faults) or each object (which makes your 
objects larger).

There's little or no advantage to a dynamic layout in this case.



More information about the Digitalmars-d mailing list