多重继承的确切问题是什么? [英] What is the exact problem with multiple inheritance?

查看:91
本文介绍了多重继承的确切问题是什么?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我可以看到人们一直在问,下一个版本的C#或Java是否应该包含多重继承.幸运的是,拥有这种能力的C ++人士说,这就像在给某人一条绳索来最终使自己吊死.

多重继承有什么关系?有没有具体样品?

解决方案

最明显的问题是函数覆盖.

假设有两个类AB,它们都定义了方法doSomething.现在,您定义了第三个类C,该类同时继承了AB,但是您没有覆盖doSomething方法.

当编译器将此代码植入种子时...

C c = new C();
c.doSomething();

...应使用该方法的哪个实现?没有任何进一步的澄清,编译器就不可能解决歧义.

除了覆盖之外,多重继承的另一个大问题是内存中物理对象的布局.

诸如C ++和Java和C#之类的语言会为每种类型的对象创建基于地址的固定布局.像这样:

class A:
    at offset 0 ... "abc" ... 4 byte int field
    at offset 4 ... "xyz" ... 8 byte double field
    at offset 12 ... "speak" ... 4 byte function pointer

class B:
    at offset 0 ... "foo" ... 2 byte short field
    at offset 2 ... 2 bytes of alignment padding
    at offset 4 ... "bar" ... 4 byte array pointer
    at offset 8 ... "baz" ... 4 byte function pointer

当编译器生成机器代码(或字节码)时,它将使用这些数字偏移量来访问每个方法或字段.

多重继承非常棘手.

如果类C继承自AB,则编译器必须决定是按AB顺序还是按BA顺序布局数据.

但是现在想象一下,您正在调用B对象上的方法.真的只是B吗?还是实际上是一个C对象通过其B接口被多态调用?根据对象的实际身份,物理布局将有所不同,并且无法知道要在调用站点调用的函数的偏移量.

处理这种系统的方法是放弃固定布局方法,允许在 尝试调用功能或访问其字段之前查询每个对象的布局.

>

因此...长话短说...对于支持多重继承的编译器作者来说,这是一个痛苦的时刻.因此,当像Guido van Rossum这样的人设计python或当Anders Hejlsberg设计c#时,他们知道支持多重继承将使编译器的实现变得更加复杂,并且大概他们认为这样做并不值得. >

I can see people asking all the time whether multiple inheritance should be included into the next version of C# or Java. C++ folks, who are fortunate enough to have this ability, say that this is like giving someone a rope to eventually hang themselves.

What’s the matter with multiple inheritance? Are there any concrete samples?

解决方案

The most obvious problem is with function overriding.

Let's say have two classes A and B, both of which define a method doSomething. Now you define a third class C, which inherits from both A and B, but you don't override the doSomething method.

When the compiler seed this code...

C c = new C();
c.doSomething();

...which implementation of the method should it use? Without any further clarification, it's impossible for the compiler to resolve the ambiguity.

Besides overriding, the other big problem with multiple inheritance is the layout of the physical objects in memory.

Languages like C++ and Java and C# create a fixed address-based layout for each type of object. Something like this:

class A:
    at offset 0 ... "abc" ... 4 byte int field
    at offset 4 ... "xyz" ... 8 byte double field
    at offset 12 ... "speak" ... 4 byte function pointer

class B:
    at offset 0 ... "foo" ... 2 byte short field
    at offset 2 ... 2 bytes of alignment padding
    at offset 4 ... "bar" ... 4 byte array pointer
    at offset 8 ... "baz" ... 4 byte function pointer

When the compiler generates machine code (or bytecode), it uses those numeric offsets to access each method or field.

Multiple inheritance makes it very tricky.

If class C inherits from both A and B, the compiler has to decide whether to layout the data in AB order or in BA order.

But now imagine that you're calling methods on a B object. Is it really just a B? Or is it actually a C object being called polymorphically, through its B interface? Depending on the actual identity of the object, the physical layout will be different, and its impossible to know the offset of the function to invoke at the call-site.

The way to handle this kind of system is to ditch the fixed-layout approach, allowing each object to be queried for its layout before attempting to invoke the functions or access its fields.

So...long story short...it's a pain in the neck for compiler authors to support multiple inheritance. So when someone like Guido van Rossum designs python, or when Anders Hejlsberg designs c#, they know that supporting multiple inheritance is going to make the compiler implementations significantly more complex, and presumably they don't think the benefit is worth the cost.

这篇关于多重继承的确切问题是什么?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆