-
Notifications
You must be signed in to change notification settings - Fork 261
Open
Description
When profiling my application, I noticed a copy when using a move assignment operator. Apparently it's not implemented, so it fallback to traditional assignment operator.
diff -r 24309a961575 external/sparsepp/spp.h
--- a/external/sparsepp/spp.h Sat Jan 27 14:47:31 2018 -0800
+++ b/external/sparsepp/spp.h Sat Jan 27 14:47:33 2018 -0800
@@ -2928,14 +2928,7 @@ public:
{
}
- sparse_hashtable& operator=(sparse_hashtable&& o)
- {
- using std::swap;
-
- sparse_hashtable tmp(std::move(o));
- swap(tmp, *this);
- return *this;
- }
+ sparse_hashtable& operator=(sparse_hashtable&& o) = default;
#endif
sparse_hashtable(MoveDontCopyT mover,
@@ -3732,6 +3725,8 @@ public:
const allocator_type& alloc) :
rep(std::move(o.rep), alloc)
{}
+
+ sparse_hash_map& operator=(sparse_hash_map &&o) = default;
#endif
#if !defined(SPP_NO_CXX11_HDR_INITIALIZER_LIST)
If I have some time on next week I'll open a pull request for this.
If not, I'd like to point out that when enabling the move assignment operator on sparse_hash_map, I got a stack overflow.
It turns out the sparse_hashtable move assignment operator is problematic. The stack I got was ugly because of the templates, but I believe that std::swap is calling operator=, and operator= is calling swap, leading to infinite recursion.
The change to the default definition of sparse_hashtable move assignment operator fixed the issue.
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
No labels