高效擦除 tr1::unordered_map 中的元素
我正在尝试 tr1::unordered_map 并偶然发现了如何解决这个问题 有效删除元素。 “擦除”方法可以通过按键或 通过迭代器。我认为后者更有效率，因为前者 大概涉及隐式查找操作。另一方面我的调查 网上有透露迭代器调用后可能会失效 insert() 方法。
我对典型的现实情况感兴趣，其中对象放入哈希表中 具有足够长的生命周期，以便在此期间发生对 insert() 的调用 寿命。因此我可以得出结论，在这种情况下，通过键删除是唯一的方法 剩下的选项？有没有其他方法可以更有效地删除对象？我是 充分意识到这个问题只在发生删除的应用程序中重要 经常。我当前的项目是否会出现这种情况还有待观察，但是 我宁愿在设计项目时了解这些问题，而不是在设计项目时了解这些问题 已经有很多代码了。
I am experimenting with tr1::unordered_map and stumbled upon the problem how to
efficiently delete elements. The 'erase' method offers to delete either by key or
by iterator. I would assume the latter to be more efficient, since the former
presumably involves an implicit find operation. On the other hand my investigations
on the internet have revealed that iterators may become invalid after calling
the insert() method.
I am interested in a typical real-world situation, where objects put into a hash table
have a life span which is long enough such that calls to insert() happen during that
life span. Thus may I conclude that in such a situation deletion by key is the only
option left? Are there any alternatives how to delete objects more efficiently? I am
fully aware that the question only matters in applications, where deletions happen
often. Whether this will be the case for my current project, remains to be seen, but
I would rather learn about these issues while designing my project rather than when
there is already a lot of code present.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
无序容器的全部目的是拥有尽可能最快的查找时间。担心按键删除元素所需的时间听起来像是过早优化的典型例子。
The whole point of the unordered containers is to have the fastest possible lookup time. Worrying about the time it takes to erase an element by key sounds like the classic example of premature optimization.
如果它对你来说很重要，因为你出于其他原因保留迭代器，那么 C++0x 在 23.2.5 中提到
std::unordered_map（引用自 FDIS） /11：我还没有检查 tr1 规范是否具有相同的保证，但基于预期的实现，它是相当合乎逻辑的。
如果您可以使用此保证，那么您可以在一定程度上保护您的迭代器。不过，正如 Mark 所说，
unordered_map中的查找应该很快。在向量中保留键而不是迭代器比在向量中保留索引而不是迭代器更糟糕，但比在映射中保留索引要好。If it matters a great deal to you, because you're keeping the iterator for some other reason, then C++0x says of
std::unordered_map(quoting from the FDIS), in 23.2.5/11:I haven't checked whether the
tr1spec has the same guarantee, but it's fairly logical based on the expected implementation.If you can use this guarantee, then you can protect your iterators up to a point. As Mark says, though, lookup in
unordered_mapis supposed to be fast. Keeping a key rather than an iterator is worse than keeping an index rather than an iterator in avector, but better than the equivalent formap.是的，
insert()可以使所有迭代器无效。因此，我认为没有办法避免（隐式）查找。好消息是后者可能很便宜。Yes,
insert()can invalidate all iterators. Therefore, I don't think there's a way to avoid the (implicit) lookup. The good news is that the latter is likely to be cheap.