Skip to content

Commit cc10788

Browse files
committedMay 23, 2019
Remove the last use of memmove. NFC.
Much clearer!
1 parent fabffba commit cc10788

File tree

1 file changed

+2
-4
lines changed

1 file changed

+2
-4
lines changed
 

‎src/mesh.cpp

+2-4
Original file line numberDiff line numberDiff line change
@@ -186,17 +186,15 @@ void SMesh::Simplify(int start) {
186186
if(fabs(bDot) < LENGTH_EPS && fabs(dDot) < LENGTH_EPS) {
187187
conv[WRAP((j+1), convc)] = c;
188188
// and remove the vertex at j, which is a dup
189-
memmove(conv+j, conv+j+1,
190-
(convc - j - 1)*sizeof(conv[0]));
189+
std::move(conv+j+1, conv+convc, conv+(convc-1));
191190
convc--;
192191
} else if(fabs(bDot) < LENGTH_EPS && dDot > 0) {
193192
conv[j] = c;
194193
} else if(fabs(dDot) < LENGTH_EPS && bDot > 0) {
195194
conv[WRAP((j+1), convc)] = c;
196195
} else if(bDot > 0 && dDot > 0) {
197196
// conv[j] is unchanged, conv[j+1] goes to [j+2]
198-
memmove(conv+j+2, conv+j+1,
199-
(convc - j - 1)*sizeof(conv[0]));
197+
std::move_backward(conv+j+1, conv+convc, conv+j+2);
200198
conv[j+1] = c;
201199
convc++;
202200
} else {

7 commit comments

Comments
 (7)

Evil-Spirit commented on May 24, 2019

@Evil-Spirit
Collaborator

probably, performance degradation

whitequark commented on May 24, 2019

@whitequark
ContributorAuthor

Why?

Evil-Spirit commented on May 24, 2019

@Evil-Spirit
Collaborator

I remember such performance issue when profiling. Evil-Spirit@44eb1a4#diff-b7a4b1c7a3c5a4ea4f00130583590ff4R336

Evil-Spirit commented on May 24, 2019

@Evil-Spirit
Collaborator

I turn back memmove and probably get some speedup.

whitequark commented on May 24, 2019

@whitequark
ContributorAuthor

OK, that's good to know. Maybe we need to define our own std::move for POD types that will have the same interface but is faster.

Though I do not know why they couldn't just specialize std::move itself for POD types, you can use SFINAE for it, I think...

rpavlik commented on May 24, 2019

@rpavlik
Contributor

yeah I was pretty sure that std::move/std::copy is generally implemented in terms of memmove/memcpy for trivially-copyable stuff, etc. In godbolt a simple test of std::move in a vector of pod types actually turned into a bunch of MOVUPS if the range was of constant size, or a call to memmove if it wasn't: https://godbolt.org/z/t81plU

Please sign in to comment.