问题标签 [dynamic-dispatch]

我遇到了以下代码（Swift 3.1）中解释的问题：

所以我希望调用后应该打印“SubClass methodA”object1.methodB()文本。methodA()但是由于某种原因，调用了 from 协议扩展的默认实现。但是object2.methodB()呼叫按预期工作。

它是协议方法调度中的另一个 Swift 错误，还是我遗漏了一些东西并且代码正常工作？

我正在用 C++ 构建一个动画库。该库将包括一个用于建模和渲染场景的系统。系统的要求是

1. 建模与渲染分离。有关场景状态的信息应与渲染场景的过程分开存储。
2. 可扩展的建模和渲染。如果库本身定义了一个node类，则该库的用户应该能够定义一个custom_node扩展其功能的新类型node（可能通过继承，但也可能通过其他方式）。然后，用户应该能够指定一个自定义过程来呈现custom_node. 在这样做时，用户应该能够以某种方式利用库中已经存在的渲染过程。用户还应该能够定义用于渲染库节点的新过程。添加：用户应该能够定义整个渲染系统并选择使用哪个渲染场景。例如，假设该库包含一个逼真的渲染系统，但用户想要使用准系统示意图渲染系统来渲染场景。用户应该能够使用动画库在动画循环（渲染帧、更新场景、渲染下一帧等）期间使用的通用渲染接口来实现这样的渲染器。
3. 库的封装。要将库的功能扩展到自定义node和渲染过程，用户不需要编辑库的底层代码。

一种失败的方法：使用nodes 的树作为场景的模型。node创建新节点类型的子类。由于节点的子节点的类型可能要到运行时才能知道，所以节点的子节点存储在vector<std::shared_ptr<node>>. 还定义一个顶级renderer类和子类renderer以提供特定类型的渲染。

要渲染场景，请定义渲染器

并使用您最喜欢的遍历方法遍历节点树。当你遇到每一个std::shared_ptr<node> n，打电话

这种方法将建模和渲染分开，并且允许可扩展性。要创建一个custom_node，库的用户只需子类node

在我们尝试提供一种自定义方式来呈现我们的custom_node. 为此，我们尝试子类renderer化和重载该render方法：

就其本身而言，这是行不通的。考虑：

为了根据需要调用 custom_renderer::render(custom_node &n)，我们需要在原始渲染器类中添加一个虚拟重载：

不幸的是，这破坏了库的封装，因为我们已经编辑了其中一个库类。

那么，我们如何设计一个满足所有 3 个要求的系统呢？

我有以下代码：

当我尝试编译它时，我收到错误消息：

我想我知道它为什么会发生，但是我如何从结构中引用特征呢？可能吗？也许还有其他方法可以实现相同的行为？

我想了解 java 中的对象是如何在内部表示的，由指向字段和函数的“指针”组成 vtables 以及在进行分配、隐式转换和显式转换时这些内部表示如何变化，以及静态和动态类型如何变化检查工作。

考虑一个扩展自：Java 中的动态方法调度的示例

对象是如何在内存中构造的？当有赋值（或等效的参数传递）时会发生什么？在以下情况下，对象的内存表示有什么区别？

当有明确的向上/向下转换时，内存表示会发生什么？它如何检查是否允许这种强制转换，以及它如何更改内部表示和方法调用调度信息。

我一直在寻找有关这些主题的资源，但没有找到任何好的资源。如果这个主题太宽泛，如果我能得到一个可以研究这个的方向，那将是有帮助的。

I am new to java and was reading about dynamic dispatching. I tried its program but the output that I got was unexpected. So in the following code I made two classes one Parent and another Child and in the Child class I made object of Child class and refer it by the variable of type Parent class. When I used the that variable to print the value of i(int type instance variable of both class) I got the value of parent class but it should print value of i that is in the child class. Can anybody please clear this up?

1. 发送字符串和发送符号以动态调用方法有什么区别，例如foo.public_send(:bar)vs foo.public_send('bar')？这些处理方式是否有具体区别？

2. foo.public_send('bar'.to_sym)如果符号更好，如果出于某种原因需要将方法名称构造为字符串，是否值得这样做？

I'm using a trick I've learnt in F# to simulate existential types, and I want to see if this works in Rust:

(gist)

The double-interface layer hides the intermediate 'c existential type in the composition behind the first interface (SuperArrowCompose<'a,'b> in the comment at the top).

The reason this works in F# is that it can dynamically generate the code needed for the 'r-specific implementation at runtime. This clearly isn't possible in Rust and it won't allow me to have a trait with generic type parameters:

It needs to be generic to allow it to be generic on the return type, but at the same time it needs to be dynamic to hide the specific C type that joins the two functions.

偶然地，我发现你可以在编译器不抱怨的情况下做到这一点：

更奇怪的是，这实际上计算为 1000：

• 扩展似乎隐藏了原始成员。

所以我尝试用我自己的班级来做到这一点：

• 并且它无法编译：“'a' 的重新声明无效”。

我观察到这不会影响通过协议对原始成员的使用，这是隐藏的预期行为：

你能解释一下为什么会出现子弹头现象吗？

说

我们有，

我们知道这是真的，

有没有办法以编程方式告诉 v 的静态绑定正是 B ？

编辑：最初的想法是对重载方法进行单行检查。就像是，

可以引入进程（B b）；但是，进程（A a）中有很多复制代码。

我有以下java代码。

它打印

• 当调用 a.method1() 时，运行时到底发生了什么？
• 如何从父级调用派生方法？
• 它是在查看对象和方法名称字符串并在运行时调用方法吗？
• 它是默认调用 this.method2() 吗？