为什么STD :: SET不提供TRY_EMPLECE成员函数?
std::map
(和 std::unordered_map
)的 try_emplace
成员函数的一个优点是,如果地图中已存在密钥。我想知道为什么这个成员函数没有添加到 std::set(和 std::unordered_set)接口中,同样的优点也可能适用。
此现场演示显示 std::set::emplace
每次都会分配: https:/ /godbolt.org/z/MjMjPcc89(使用 libstdc++)。
此基准测试表明,当存在重复键时,find
+ emplace
可能比单独使用 emplace
更快:https://quick-bench.com/q/2IWzv_SJFJpklGjwIKk6wgKsuz0。
但是,find
+ emplace
需要双重查找,以防容器中不存在该键。以下是 std::map
的基准,其中 try_emplace
是最快的选项:https://quick-bench.com/q/ymn1qaxAtrf6FTzHC98e_wkHVZ4。
编辑
使用std::set::insert
时似乎不会出现分配问题。可惜我之前没试过。
One advantage of try_emplace
member function of std::map
(and std::unordered_map
) is that it does not allocate a new node if the key already exists in the map. I wonder why this member function has not been added to the std::set
(and std::unordered_set
) interface, where the same advantage might apply as well.
This live demo shows that std::set::emplace
allocates each time: https://godbolt.org/z/MjMjPcc89 (with libstdc++).
And this benchmark shows that find
+ emplace
may be faster than emplace
alone when there are duplicated keys: https://quick-bench.com/q/2IWzv_SJFJpklGjwIKk6wgKsuz0.
However, find
+ emplace
requires a double lookup in case the key is not present in the container. Here is the benchmark for std::map
, where try_emplace
is the fastest option: https://quick-bench.com/q/ymn1qaxAtrf6FTzHC98e_wkHVZ4.
EDIT
It seems the problem with allocations does not occur when std::set::insert
is used. My bad I haven't tried it before.
Live demo: https://godbolt.org/z/EjWjfjnsc
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
std :: set :: set :: emplace ://en.cppreference.com/w/cpp/container/unordered_set/emplace“ rel =“ nofollow noreferrer”> std :: unordered_set :: emplace 已经等同于
try> try_emplace
:但是,请注意:
std::set::emplace and std::unordered_set::emplace are already equivalent to
try_emplace
:However, be aware that: