在 C++ 代码生成器中模仿 C#'new'（隐藏虚拟方法）答案

【问题标题】：Mimicing C# 'new' (hiding a virtual method) in a C++ code generator在 C++ 代码生成器中模仿 C#'new'（隐藏虚拟方法）
【发布时间】：2013-11-22 02:00:19
【问题描述】：

我正在开发一个系统，它采用一组已编译的 .NET 程序集并发出 C++ 代码，然后可以将其编译到任何具有 C++ 编译器的平台。当然，这涉及到一些广泛的技巧，因为 .NET 做了很多 C++ 没有做的事情。

其中一种情况是能够隐藏虚拟方法，例如 C# 中的以下内容：

class A
{
    virtual void MyMethod()
    { ... }
}

class B : A
{
    override void MyMethod()
    { ... }
}

class C : B
{
    new virtual void MyMethod()
    { ... }
}

class D : C
{
    override void MyMethod()
    { ... }
}

我想出了一个看起来很聪明并且确实有效的解决方案，如下例所示：

namespace impdetails
{
template<class by_type>
struct redef {};
}

struct A
{
    virtual void MyMethod( void );
};

struct B : A
{
    virtual void MyMethod( void );
};

struct C : B
{
    virtual void MyMethod( impdetails::redef<C> );
};

struct D : C
{
    virtual void MyMethod( impdetails::redef<D> );
};

这当然需要C::MyMethod 和D::MyMethod 的所有调用站点构造并传递虚拟对象，如下例所示：

C *c_d = &d;
c_d->MyMethod( impdetails::redef<C>() );

我不担心这个额外的源代码开销；该系统的输出主要不用于人类消费。

不幸的是，事实证明这实际上会导致 runtime 开销。直观地说，由于impdetails::redef<> 是空的，它不会占用空间，并且传递它不会涉及任何代码。

但是，出于我理解但不完全同意的原因，C++ 标准规定对象的大小不能为零。这给我们留下了编译器实际发出代码来创建和传递对象的情况。

事实上，至少在 VC2008 上，我发现它甚至会遇到将虚拟字节归零的麻烦，即使在发布版本中也是如此！我不知道为什么那是必要的，但这让我更不想这样做。

如果一切都失败了，我总是可以更改函数的实际名称，例如可能有MyMethod、MyMethod$1 和MyMethod$2。然而，这会导致更多的问题。例如，$ 在 C++ 标识符中实际上是不合法的（尽管我测试过的编译器允许这样做。）输出程序中完全可接受的标识符也可能是输入程序中的标识符，这表明更复杂的方法将需要，这使得它的吸引力降低。

事实证明，在这个项目中还有其他情况，如果能够使用任意类型参数修改方法签名会很好，类似于我将类型传递给impdetails::redef<>。

有没有其他聪明的方法来解决这个问题，还是我在每个呼叫站点增加开销或修改名称之间陷入困境？

【问题讨论】：

为什么不给函数起一个不同的名字呢？相同的效果——从“基本”函数更改其签名——但不添加参数。
@CoryNelson 最坏的情况是，我总是可以修改方法名称。但这确实会导致一些问题。例如，任何在输出程序中合法的标识符在输入程序中也是合法的，这意味着如果生成器使用一些琐碎的修改，生成的名称可能是不明确的。更复杂的转换可以避免这种歧义，但理想情况下我试图避免这种混乱。我还有其他类似的情况（与泛型有关），其中标识符可能最终不得不包含非平凡的类型信息，这会使处理进一步复杂化。

标签： c++ code-generation

【解决方案1】：

在考虑了系统的其他一些方面以及 .NET 中的接口之后，我开始认为甚至根本不使用 C++ 虚拟调用机制可能会更好——甚至可能或多或少有必要。我考虑得越多，使用这种机制就越混乱。

在这种方法中，每个用户对象类都将有一个单独的 vtable 结构（可能保存在单独的命名空间中，如 vtabletype::。生成的类将有一个指针成员，该指针成员将通过一些技巧初始化以指向vtable 的静态实例。虚拟调用将显式使用来自该 vtable 的成员指针。

如果操作正确，这应该与编译器自己的实现具有相同的性能。我已经确认它在 VC2008 上确实如此。（相比之下，仅使用我之前计划的直接 C，可能不会表现得那么好，因为编译器经常将this 优化到一个寄存器中。）

手动编写这样的代码会很糟糕，但当然这对生成器来说不是问题。这种方法在这个应用中确实有一些优势：

由于它是一种更加明确的方法，因此可以更加确定它完全按照 .NET 指定的方式执行了与 newslot 相关的操作以及接口实现的选择。
它可能比更传统的 C++ 接口方法更有效（取决于一些内部细节），后者往往会调用多重继承。
在 .NET 中，对象在其.ctor 运行时被认为是完全构造的。这会影响虚函数的行为方式。有了对 vtable 的明确了解，这可以通过在分配期间将其写入来实现。（虽然将.ctor 代码放入普通的成员函数是另一种选择。）
实现反射时可能会避免冗余数据。
它提供了更好的对象布局控制和知识，这对于垃圾收集器可能很有用。

不利的一面是，它完全失去了 C++ 编译器关于 vtable 条目的重载特性：这些条目是数据成员，而不是函数，因此没有重载。在这种情况下，只为成员编号（比如_0、_1...）会很诱人，这在调试时可能不会那么糟糕，因为一旦跟随指针，你会看到一个实际的、正确的-无论如何命名的成员函数。

我想我最终可能会这样做，但无论如何我想知道是否有更好的选择，因为这无疑是一个相当复杂的方法（和问题）。

【讨论】：