Comments on: How Compact Code Can Become Buggy Code: Getting Caught By The Order of Evaluations https://www.fluentcpp.com/2017/05/09/compact-code-becomes-buggy-code-order-evaluations/ Jonathan Boccara's blog Mon, 02 Oct 2017 20:33:07 +0000 hourly 1 https://wordpress.org/?v=6.5.4 By: Jeremy Demeule https://www.fluentcpp.com/2017/05/09/compact-code-becomes-buggy-code-order-evaluations/#comment-261 Wed, 10 May 2017 20:31:00 +0000 https://www.fluentcpp.com/?p=1134#comment-261 Hello Jonathan,

I do not think the compactness of the code nor the evaluation order have something to do with the issue you are trying to expose.
When a function take a reference/pointer as parameters, it expect parameters are valid during the call and independent. This is the default/implicit contract. This is not something new, memcpy and memmove (with the same prototype before C99) forbid, and respectively accept, overlapping parameters.

This is also what Herb Sutter explain during his CppCon 2015 keynote (Writing Good C++14… By Default [slide 50]).

I think this is the responsibility of the caller the respect the contract. Else, the behavior is undefined and this is was you see here. Something is working, sometimes not, order of evaluation is just a way to raise this issue.

]]> By: Andrey Upadyshev https://www.fluentcpp.com/2017/05/09/compact-code-becomes-buggy-code-order-evaluations/#comment-256 Tue, 09 May 2017 13:12:00 +0000 https://www.fluentcpp.com/?p=1134#comment-256 Thank you for a good article. I want to add that in most cases (all cases from my experience) it’s better to pass unique_ptr by rvalue reference. Then your example is safe :). But it’s not only about this particular case. Passing by reference allows callee to decide when to do the actual move thus for example, in case of exception callee can leave the pointer unmoved and caller still owns the object and can do some other operation with it or whatewer. That’s not possible if unique_ptr is passed by value.

]]>