3 ms·

`return opt.value()` is not forced to be a copy, no. It is, as you noted, a reference return. You can of course continue to propagate that as a reference if you

`return opt.value()` is not forced to be a copy, no. It is, as you noted, a reference return. You can of course continue to propagate that as a reference if you want, assuming that makes sense. I don't think I'd agree with a characterization that `value_or` is a footgun? It behaves basically identically to similar features in every other language (like Java's Optional#orElse). If it somehow changed parameter evaluation such that it was deferred then that would be a footgun. But it's of course not doing that.

tsimionescu 4y ago
I'm calling value_or a footgun because it calls both the initial constructor (which is to be expected, as in Java) but, if I understand correctly, a further copy constructor (perhaps ellided if the conditions are right). In Java/C#/Python/Ruby/Haskell/Rust etc, this copy would be guaranteed not to happen (at the cost of a heap allocation in the first 4, in most cases). Of course, even in Java this method is often inferior - it only really makes sense in languages like Haskell or if replaced by a macro of some kind, which would guarantee that the unnecessary value is neither constructed nor copied. Otherwise, an if/else or ? should generally be preferred, especially in a performance-focused language like C++.
- kllrnohj 4y ago
  https://en.cppreference.com/w/cpp/utility/optional/value_or https://en.cppreference.com/w/cpp/utility/optional/value_or value_or's parameter type is U&&, so no there's no additional copy there. There's only the explicitly visible default constructor call. But you did get me to take a second look at the post, and yeah the author's statement of "Finally, we copy construct an instance of A when the call to value_or terminates." is just incorrect. Try it out yourself: https://godbolt.org/z/hWqnrfGKE https://godbolt.org/z/hWqnrfGKE If you replace the `.value_or(A())` with `.value()` there's no reduction in copies, only a single reduction in the constructed count which of course makes sense since the `A()` parameter isn't there. The way you would optimize this to eliminate copies would be to do things like construct the optional in-place and take the parameter by const& instead, such as: A f(const std::optional<A>& z) { return z.value_or(A()); } A g() { std::optional<A> z(std::in_place, "message"); return f(z); } `std::in_place` being definitely a classic C++ "quirk" here and usually unlikely to be worth it but hey if you want to play "minimize the copy count" golf there you go. The value_or isn't actually adding any copies, though.

tsimionescu 4y ago

I'm calling value_or a footgun because it calls both the initial constructor (which is to be expected, as in Java) but, if I understand correctly, a further copy constructor (perhaps ellided if the conditions are right). In Java/C#/Python/Ruby/Haskell/Rust etc, this copy would be guaranteed not to happen (at the cost of a heap allocation in the first 4, in most cases). Of course, even in Java this method is often inferior - it only really makes sense in languages like Haskell or if replaced by a macro of some kind, which would guarantee that the unnecessary value is neither constructed nor copied. Otherwise, an if/else or ? should generally be preferred, especially in a performance-focused language like C++.

kllrnohj 4y ago
https://en.cppreference.com/w/cpp/utility/optional/value_or https://en.cppreference.com/w/cpp/utility/optional/value_or value_or's parameter type is U&&, so no there's no additional copy there. There's only the explicitly visible default constructor call. But you did get me to take a second look at the post, and yeah the author's statement of "Finally, we copy construct an instance of A when the call to value_or terminates." is just incorrect. Try it out yourself: https://godbolt.org/z/hWqnrfGKE https://godbolt.org/z/hWqnrfGKE If you replace the `.value_or(A())` with `.value()` there's no reduction in copies, only a single reduction in the constructed count which of course makes sense since the `A()` parameter isn't there. The way you would optimize this to eliminate copies would be to do things like construct the optional in-place and take the parameter by const& instead, such as: A f(const std::optional<A>& z) { return z.value_or(A()); } A g() { std::optional<A> z(std::in_place, "message"); return f(z); } `std::in_place` being definitely a classic C++ "quirk" here and usually unlikely to be worth it but hey if you want to play "minimize the copy count" golf there you go. The value_or isn't actually adding any copies, though.