c++ - 在 C++ 代码生成器中模仿 C# 'new'(隐藏虚方法)

Question

我正在开发一个系统，它采用一组已编译的 .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>() );

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

不幸的是，事实证明这实际上会导致运行时 开销。直觉上，人们会期望因为 impdetails::redef<>是空的，它不会占用空间，传递它也不会涉及任何代码。

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

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

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

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

是否有任何其他聪明的方法来解决这个问题，或者我是否陷入了在每个调用站点增加开销或修改名称之间？

Answer 1

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

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

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

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

• 因为这是一种更明确的方法，所以可以更加确定它正在执行 .NET 指定的关于 newslot 以及接口(interface)实现选择的操作。

• 它可能比更传统的 C++ 接口(interface)方法更有效(取决于一些内部细节)，后者往往会调用多重继承。

• 在 .NET 中，当对象的 .ctor 运行时，对象被认为是完全构建的。这会影响虚函数的行为方式。有了 vtables 的明确知识，这可以通过在分配期间写入它来实现。 (尽管将 .ctor 代码放入普通成员函数中是另一种选择。)

• 在实现反射时可能会避免冗余数据。

• 它提供了更好的对象布局控制和知识，这对垃圾收集器很有用。

不利的一面是，它完全失去了 C++ 编译器对 vtable 条目的重载功能:这些条目是数据成员，而不是函数，因此没有重载。在这种情况下，很容易只给成员编号(比如 _0、_1...)这在调试时可能不会太糟糕，因为一旦指针被跟踪，无论如何您都会看到一个实际的、正确命名的成员函数。

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