是否有理由使用字符串 => 索引到向量的映射，而不是字符串 => 对象？答案

【问题标题】：Is there a reason to use a mapping of string => index into a vector, instead of string => object?是否有理由使用字符串 => 索引到向量的映射，而不是字符串 => 对象？
【发布时间】：2015-02-18 01:11:10
【问题描述】：

如果我有一组我希望能够按名称查找的对象，我当然可以使用 { string => object } 映射。

是否有理由使用对象的向量以及{ string => index into this vector }伴随地图？

多年来，我已经看到许多开发人员这样做，但我基本上认为这表明开发人员不熟悉地图，或者在其他方面感到困惑。但是最近几天，我开始怀疑自己，我担心我可能会错过潜在的优化或其他东西，尽管我一生都无法弄清楚可以优化什么。

【问题讨论】：

如果您首先拥有向量，或者想保持其顺序，则可以使用您描述的方案。它在概念上与带有索引的数据库文件的概念相匹配。
如果你需要一个对象向量，但也需要一个字符串->对象映射怎么办？它还允许您非常轻松地更改名称->对象映射，或者允许您将多个名称映射到同一个对象。
在垃圾收集的世界中，不让对象保持活动状态可能是安全的。将“索引”（字符串+索引）的存储与核心数据（对象）分开会很有用

标签： java c++ performance optimization data-structures

【解决方案1】：

我能想到的原因有一个：

除了按名称查找对象外，有时您还希望尽可能高效地遍历所有对象。使用地图+矢量可以实现这一点。通过索引访问向量会付出很小的代价，但是通过迭代向量而不是映射可以大大提高性能（因为向量在连续内存中并且对缓存更友好）。

当然你可以使用 boost::multiindex 做类似的事情，但是这对对象本身有一些限制。

【讨论】：

【解决方案2】：

我至少能想到几个原因：

出于不相关的原因，您需要保留广告订单。
您希望多个映射指向向量（不同的索引）。
并非向量中的所有项都需要由字符串指向。

【讨论】：

【解决方案3】：

没有优化。如果您考虑一下，它实际上可能会降低性能（尽管会降低几微纳秒）。这是因为基于向量的“解决方案”需要额外的步骤才能在向量中找到对象，而非基于向量的解决方案则不必这样做。

【讨论】：