【问题标题】:What container to choose选择什么容器
【发布时间】:2011-04-08 17:44:40
【问题描述】:

我想存储一些对象......现在我不知道该选择什么。

所以,现在我有这样的代码:

std::map<std::string, Object*> mObjects;

但是,正如我之前在这里所说的,由于每次搜索都分配了std::string,所以速度很慢,所以键应该是整数。

为什么我选择std::string 作为键?因为通过名称访问对象非常容易,例如:

mObjects["SomeObj"];

所以我的第一个想法是:

std::map<int, Object*> mObjects;

并且key是对象名称的CRC:

mObjects[CRC32("SomeObject")];

但它有点不稳定。我知道这有特殊的哈希映射。 最后,我必须使用 Compare 函数对地图中的对象进行排序。

关于我可以使用的容器有什么想法吗?

再说一遍,要点:

  • 通过字符串访问对象,但键应该是整数,而不是字符串
  • 按某些功能对地图中的对象进行排序

附言提升使用是允许的。

【问题讨论】:

  • 在说它很慢之前,您是否先使用字符串键测量了性能?
  • 是由于运行时的限制而需要的字符串,还是编译时已知的所有值,可以用常量替换,例如:const int SOME_OBJECT = 1; ... mObject[SOME_OBJECT] ...
  • @thanatos 不,他们不能。有近 1000 个对象。
  • 你能用unordered_map吗?
  • 您可以查看 Boost.MultiIndex,它允许您在同一个容器中以各种方式索引项目。您可以使用散列索引进行快速搜索,并使用有序索引进行排序。

标签: c++ boost map containers


【解决方案1】:

我不能肯定地说,但是您是否总是通过文字字符串访问地图中的项目?如果是这样,那么您应该只使用带有符号名称的连续枚举值,以及适当大小的vector

假设您直到运行时地图中的 1000 个项目才知道名称,这对于搜索可能是一个瓶颈来说似乎真的很小。您确定查找是性能问题吗?您是否进行了分析以确保是这种情况?一般来说,使用最直观的容器会产生更好的代码(因为你可以更容易地掌握算法)。

您关于构造字符串的评论是否暗示您一遍又一遍地将 C 字符串传递给 find 函数?尝试通过在您的应用程序中始终使用std::string 来避免这种情况。

如果您坚持使用两部分方法:我建议将所有项目存储在vector 中。然后你有一个unordered_map 从字符串到索引,另一个vector 将所有索引都放在主容器中。然后对第二个索引容器进行排序以获得所需的排序。最后,当您从主容器中删除项目时,您需要清理其他两个引用容器。

【讨论】:

  • 地图呢。我调用搜索大约 250 个对象,每个 ~11 毫秒。是小数吗?而且它们都每 11 毫秒迭代一次。我认为, boost::multiindex 正是我所需要的。
  • 您能否发布用于搜索/迭代地图的代码,因为(如果我理解正确的数字)时间非常长。是否构建发布版本的代码,有时调试版本很慢。
  • @Ockonal 你没有在地图上使用std::find 是吗?
猜你喜欢
  • 2019-12-31
  • 2012-07-05
  • 2016-12-08
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2014-07-26
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多