【问题标题】:Efficient way to generate id unique to class?生成类独有的id的有效方法?
【发布时间】:2011-06-15 22:20:30
【问题描述】:

在 C++ 中是否有任何有效的方法来生成类唯一的 ID,而不是实例?我正在寻找这种简单程度的东西(这会为每个实例生成一个 ID,而不是为每个类类型生成一个 ID):

MyClass::MyClass()
{
    static unsigned int i = 0;
    id_ = i++;
}

编辑:为什么我需要唯一 ID。

我正在写一个游戏。我游戏中的所有实体都会有不同的状态(左走、跳跃、站立等);这些状态在类中定义。每个州都需要有自己的 ID,以便我识别它。

【问题讨论】:

  • typeidtype_info 尽管这些通常仅用于调试目的,所以我只使用枚举或字符串标识符。你想要完成什么需要你有一个类型 ID 列表,因为可能有更好的方法...... C++ 是强类型的,所以所有类型都已经具有固有的唯一性。
  • @AJG85 在生产代码中使用typeid 是不好的做法吗?这似乎是目前对我来说最好的事情。
  • 我认为它在生产代码中是不好的做法。首先,因为它是一个运行时构造,不能保证返回任何人类可读的 .name 内容,其次因为 C++0x 引入了 decltypeauto,这应该可以减轻模板代码中的一些类型检查需求,这可能是唯一应该考虑这样的地方。

标签: c++ algorithm performance


【解决方案1】:

你可以试试这个,但它不是确定性的。

int id_count = 0;

template <typename T>
int get_id()
{
    static int id = id_count++;
    return id;
}

然后只需使用:

get_id<int>(); // etc.

当然,这不是线程安全的。

同样,它不是确定性的:ID 是在您第一次调用每种类型的函数时生成的。因此,如果在一次运行中您在get_id&lt;float&gt;() 之前调用get_id&lt;int&gt;(),那么在另一次运行中您反过来调用它们,那么它们将具有不同的ID。但是,它们在一次运行中对于每种类型始终是唯一的。

【讨论】:

  • 这是一个很好的解决方案,因为我的应用程序不是多线程的。问题是我无法在编译时知道所有类型。在编译时只知道基类,派生类将在脚本中定义。我需要每个派生类的唯一 ID。
  • @Paul:如果类型来自脚本,那么您将需要特定于您使用的脚本语言的解决方案。
  • 我希望有一些巧妙的方法来处理静态变量,允许基类(在编译时已知)为从它派生的每个类生成唯一的 ID。
  • @Paul:就您的代码的 C++ 部分而言,没有人确实派生自您的类。你不关心 C++;您的问题的解决方案取决于您的脚本语言,以及它与现有 C++ 代码的交互方式。
【解决方案2】:

基本上,您要求的是自定义滚动 RTTI 解决方案,您可以有选择地应用于课程。

这可以从非常粗糙的预处理器开始,例如:

#define DECLARE_RTTI_CLASS(a) class a {  \
     inline const char * class_id() { return #a };

.. 到跟踪继承等的更复杂的解决方案,基本上部分复制了编译器 RTTI 功能。例如,请参阅 Game Programming Gems #2,Dynamic Type Information

same subject 之前关于 gamedev 的讨论也是worth reading

【讨论】:

    【解决方案3】:

    使用您的MyClass 作为原语,并将一个静态实例合并到您要标识的每个类中。

    class MyOtherClass1 {
        static MyClass id;
    };
    
    class MyOtherClass2 {
        static MyClass id;
    };
    
    [etc.]
    

    【讨论】:

    • 我知道,但我一直在寻找更“自动”的东西。像这样手工操作很容易出错。 :)
    • @Paul:除非您使用诸如 OpenC++ 之类的工具(它甚至不再维护),否则您不能要求编译器自动丰富所有类实例:它们只包含每个类中明确列出的内容。但是,如果你的程序依赖于这些字段,那么如果它们不存在,你应该会得到一个编译时错误,这会留下你尚未提供的神秘脚本语言的详细信息(它允许你派生来自 C++ 类...)。
    • @Tony 语言是 Python。
    • @Paul:感谢您让我知道——我目前的团队经常使用 Python,但没有嵌入——开辟了可能性:-)
    猜你喜欢
    • 1970-01-01
    • 2011-01-14
    • 2020-01-25
    • 1970-01-01
    • 1970-01-01
    • 2010-11-14
    • 1970-01-01
    • 1970-01-01
    • 2015-12-19
    相关资源
    最近更新 更多