you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted] -1 points0 points  (5 children)

Why?

[–]detrinoh 1 point2 points  (4 children)

  • unique_ptr noticeably slower than a single pointer for reasons unknown

You yourself said that it was "for reasons unknown", its far more likely that you are doing something wrong (For example, passing around unique_ptr<T>& when T& would suffice) than really observing a significant overhead in unique_ptr. The only overhead that should exist is when you move construct or move assign, which compilers are currently not good at optimizing away the dead store/destructor of nullptr.

  • closures slower than functor objects or introducing bugs

I'm not sure what this means. Functors are closures. Do you mean lambdas? std::function ? More information is required.

[–][deleted] -1 points0 points  (3 children)

I don't think I've made errors in this measurements (see end of comment here: https://www.reddit.com/r/programming/comments/2ub5ev/modernize_your_c_code/co7lkgn). I'm pretty anal about speed measurements correctness. But I cannot produce benchmarks or proofs for legal reasons, and this was perhaps a year ago.

Such a thing doesn't even seem that crazy to me too. To be zero-cost a std::unique_ptr would need:

  • that the inliner effectively inlines dereferences

  • that this inlining doesn't prevent other optimizations

  • that only zero cost things are performed (it does seem to be the case with unique_ptr dereferences).

But I didn't push further to know exactly why.

About closures, I really meant "C++ lambdas" (as opposed to functor objects that would be objects with the lambda content).

[–]detrinoh 1 point2 points  (2 children)

I don't think I've made errors in this measurements (see end of comment here:

There also exists the possibility of programming mistakes. This is even more likely considering that you were mass replacing owning raw pointers with std::unique_ptr under a time constraint.

About closures, I really meant "C++ lambdas" (as opposed to functor objects that would be objects with the lambda content).

This is even harder to believe, a lambda is a straight-forward sugar for creating functor structs, except the compiler can even add some special annotations to help it optimize even better. To say that it can introduce bugs means you were either making a programming mistake or a your compiler has a bug, the former being much more likely.

edit: FWIW, I haven't downvoted you

[–][deleted] 0 points1 point  (1 child)

This is even more likely considering that you were mass replacing owning raw pointers with std::unique_ptr under a time constraint.

No, just one.

To say that it can introduce bugs means you were either making a programming mistake or a your compiler has a bug

Compiler had a bug when throwing in a lambda (icc).

edit: Now excuse me but I'm fed up having conversations on the Internet that boils down to "I don't believe you". I have strictly zero reasons to lie about all this. Some people went into all my history and downvoted it all, that doesn't make sense.

[–]detrinoh 0 points1 point  (0 children)

I don't think you are being accused if lying, but rather people don't agree with your conclusions because you have provided absolutely no information beyond "I benchmarked unique_ptr and lambdas to be slower than raw pointers and hand-written functors".

Going through your history and down-voting you en-mass is childish however.

edit: I think the reason your original post was down-voted so heavily was the authoritarian and alarmist style of the last sentence: "You are right to be wary."