什么是处理类的元方面的适当接口？

Question

我正在寻找一些关于处理类（处理类）方面的适当接口的建议，但这些方面不是他们正在处理的实际类的一部分（元-方面）。这需要一些解释...

在我的具体示例中，我需要实现一个自定义 RTTI 系统，该系统比 C++ 提供的系统稍微复杂一点（我不会详细说明为什么需要它）。我的基础对象是 FooBase ，该基础的每个子类都与一个 FooTypeInfo 对象关联。

// Given a base pointer that holds a derived type,
// I need to be able to find the actual type of the
// derived object I'm holding.
FooBase* base = new FooDerived;

// The obvious approach is to use virtual functions...
const FooTypeInfo& info = base->typeinfo();

使用虚函数来处理对象的运行时类型对我来说并不合适。我倾向于认为对象的运行时类型超出了类的范围，因此它不应该是其显式接口的一部分。下面的接口让我感觉更舒服......

FooBase* base = new FooDerived;
const FooTypeInfo& info = foo::typeinfo(base);

但是，即使接口不是类的一部分，实现仍然必须使用虚函数，才能使其工作：

class FooBase
{
   protected:
     virtual const FooTypeInfo& typeinfo() const = 0;
     friend const FooTypeInfo& ::foo::typeinfo(const FooBase*);
};

namespace foo
{
    const FooTypeInfo& typeinfo(const FooBase* ptr) {
        return ptr->typeinfo();
    }
}

你认为我应该使用这个第二个接口（感觉更适合我）并处理稍微复杂的实现，或者我应该使用第一个接口？

---

@塞斯·卡内基

如果您甚至不希望派生类知道自己是 RTTI 的一部分，那么这就是一个难题...因为您实际上无法在依赖于的 FooBase 构造函数中执行任何操作正在实例化的类的运行时类型（出于同样的原因，您不能在 ctor 或 dtor 中调用虚拟方法）。

FooBase 是层次结构的公共基础。我还有一个单独的 CppFoo<> 类模板，它减少了样板文件的数量并使类型的定义更容易。还有另一个使用 Python 派生对象的 PythonFoo 类。

template<typename FooClass>
class CppFoo : public FooBase
{
  private:
    const FooTypeInfo& typeinfo() const {
        return ::foo::typeinfo<FooClass>();
    }
};

class SpecificFoo : public CppFoo<SpecificFoo>
{
    // The class can now be implemented agnostic of the
    // RTTI system that works behind the scenes.
};

有关系统如何工作的更多详细信息可以在此处找到：
► https://stackoverflow.com/a/8979111/627005

Answer 1

您可以通过 typeid 关键字将动态类型与静态类型联系起来，并使用返回的 std::type_info 对象作为标识方式。此外，如果您将 typeid 应用于专门为此目的而创建的单独类，那么对于您感兴趣的类来说，这将是完全非侵入性的，尽管它们的名称仍然必须提前知道。重要的是，typeid 应用于支持动态多态性的类型 - 它必须具有一些virtual 函数。

这是一个例子：

#include <typeinfo>
#include <cstdio>

class Base;
class Derived;

template <typename T> class sensor { virtual ~sensor(); };

extern const std::type_info& base = typeid(sensor<Base>);
extern const std::type_info& derived = typeid(sensor<Derived>);

template <const std::type_info* Type> struct type
{
  static const char* name;

  static void stuff();
};

template <const std::type_info* Type> const char* type<Type>::name = Type->name();

template<> void type<&base>::stuff()
{
  std::puts("I know about Base");
}

template<> void type<&derived>::stuff()
{
  std::puts("I know about Derived");
}

int main()
{
  std::puts(type<&base>::name);
  type<&base>::stuff();

  std::puts(type<&derived>::name);
  type<&derived>::stuff();
}

不用说，由于 std::type_info 是正确的对象，并且它们是唯一且有序的，因此您可以在集合中管理它们，从而删除从接口查询的类型：

template <typename T> struct sensor {virtual ~sensor() {}};

struct type
{
  const std::type_info& info;

  template <typename T>
  explicit type(sensor<T> t) : info(typeid(t))
  {};
};

bool operator<(const type& lh, const type& rh)
{
  return lh.info.before(rh.info);
}

int main()
{
  std::set<type> t;
  t.insert(type(sensor<Base>()));
  t.insert(type(sensor<Derived>()));

  for (std::set<type>::iterator i = t.begin(); i != t.end(); ++i)
    std::puts(i->info.name());
}

当然可以按照您认为合适的方式混合搭配两者。

有两个限制：

• 这里没有实际的内省。您可以通过巧妙的元编程将其添加到模板结构传感器中，这是一个非常广泛的主题（有时令人费解）。
• 必须提前知道您想要支持的所有类型的名称。

一种可能的变化是添加 RTTI“框架钩子”，例如static constsensor。 rtti_MyClass; 到类名已知的实现文件，并让构造函数完成工作。此时它们还必须是完整的类型，才能在传感器中进行内省。