Should be fixed in C++29

6:19 you can just write `std::in_place`, no need to write the extra `_t{}`

I think Jason missed a point, for functions returning expected it is very likely to have branching, and in that case RVO will use move constructor most of the time anyway. The same can be said for optional (indeed if your code always return a Lifetime then the return type should be Lieftime and not optional)

This makes me appreciate Rust's "move by default." While annoying in other areas, that semantics means the compiler can optimize this kind of code well and we don't need to think about this issue

Self taught C++ in early 2000s, and have started to use it again, after work took me away from it. Have recently heard of RVO and have just started incorporating std::optional into a project I'm working on, as being able to say that there is no value to return is really helpful. And then I saw this.

This seems like something the compiler could optimize for.

I suspect a lot of people will write "return std::unexpected{"oh no!"};" and that will prevent RVO anyway (at least when I tried). I guess we will (again?) rely on tooling to fix these issues. If the compiler cannot optimize in the first place for most cases.

Thanks Jason, now I have a couple hundred APIs in several libs I need to revisit. Really, an excellent YT. You do good work.

Good to know, thanks for pointing this!

Haha, I regret no episode of yours! In fact, you did such a good job explaining RVO so far that I did not find anything you did not already cover implicitly. You just made it explicit now. Excellent series!

I have thought about this a few times. And, every time I imagined what the "fewer moves" code would look look, it seemed like a premature optimization making the code less readable; it looked more like C89 code with the variables and return value declared at the beginning of the blocks. Much cleaner to just put a couple `if (bad) return std::nullopt` around.

I know C++, kind of, but haven't actually used it in any real applications, so I don't really experience the issues I sometimes see talked about, like this one. So for those more experienced than me: how often do these sorts of things end up mattering? A lot of online C++ content loves to talk about small ways of squeezing a little bit more performance out of your code. These sorts of micro-optimisations don't strike me as the thing that will make the difference between your code being acceptably fast or not. E.g. the specific problem presented in this video. I would think that the majority of the classes you write in an application don't have anything fancy going on in their various constructors, assignment operators, and destructors. So I wouldn't think that this would make an enormous difference. Would it make your application faster? Probably. But I would think that the things to target when it comes to optimisation would be less granular. I'm happy to be wrong, so feel free to challenge my assumptions. I'm genuinely looking for an answer for why the C++ community seems focused on optimisation to such a degree.

I think there is a problem with the test setup here: The Lifetime class always have an IO side effect. These cannot be optimized away by the compiler properly! But classes following the rule of zero might not be affected ☝️ I would like to see a follow-up with optional and optional analysing the asm.

This is really unfortunate. I think you should discuss this with Arthur O Dwyer. He has proposed many papers on topic of returning objects (and implicit moves) and has also given talks on this subject. This seems like a missed optimization opportunity as far as core language is concerned. This case is very similar to the C++17 guaranteed copy-elision. We can generalized that approach to elide copying any object/value that is used to construct the returned object (given the converting constructor of the returned type itself is not explicit).

To the people thinking this is about RVO (copy elision): it is not. And by the way RVO works fine (which is why you don't see extra outputs from an internal copy of Lifetime when the optional is copied out as a return value: because it is not). The problem is when you have a Lifetime object but what you really want to return is an Optional which implicitly causes the Optional constructor to be called with a Lifetime. As this point (language-wise) the Lifetime must be materialized because the parameter is a glvalue. So Lifetime{42} is materialized as the parameter. Then the inner Lifetime is move constructed from that. The issue here is nothing to do with RVO, but with calling functions (constructors) to make a class B by passing an A and expecting the construction of A to be elided; which is won't. The resulting Optional is perfectly NVRO'ed (which is actually an optional optimization) in the first example; or (unnamed) RVOed out in the remaining cases. And RVO has nothing to do with the constructor/destructor being trivial or not (if elided those copies never existed at all!). For example: godbolt.org/z/fMKzxEbj6 . But can't the compiler optimize it away anyway? In many cases: probably sure. What it can't optimize away is the observable side effect of outputting.

+1 for the cppreference dark theme!

Awesome episode. I don't regret watching it. Now I can better remember about this specific pitfall. The worst emotion now is a frustration caused by so called "standard" which was supposed to make everyone's life easier instead of making really bad things harder to spot.

We often face the situation that our objects are returned by some sort of factory function before being placed into the optional, etc. We came up with a solution to avoid moves here. Basically all of these classes have constructors overload that participate if the contained value is constructible from another object. So we created a helper class that holds a callable and defines a conversion operator to the result type of the callable by calling it (so we get rvo there). With this class, a helper function and a lambda wrapping the original function call we were able to emplace the return value of the function directly into an optional. We did introduce a macro as we did not find it too readable though.

What about std::make_optional?

I just want you to, I don’t know… regret watching this episode Jason Turner breaks 2024

9:47 did you mean to say "more and more implicit conversions" instead of "explicit"?

Something I'm noticing: your Lifetime class is great at finding out when you might be calling an expensive operation that can't easily be optimized out. When you're using this for a pure value type this all becomes a non-issue. If you have a complicated type, it might be worth seeing if there's an empty state that can be defined and return that (e.g. an empty vector). If you have a complicated type, that's expensive to move, and can't easily have an empty state and you want to add the empty state by sticking it into an optional... then yeah, this is a problem. Personally I haven't run into it yet but that doesn't mean it's not someone else's use case.

Ah, I've run into this problem before trying to write unit tests for my own version of std::expected a couple years ago! The problem I ran into is the fact that you are creating an object like Lifetime to track your constructors and destructors / move operators. In doing so, these functions have side effects that the optimizers will explicitly NOT remove, forcing the duplicate constructors and destructors. If you don't have the observers, and just check the pure ASM, then you realize the RVO can kick in and you don't get the extra function calls. I admit that this doesn't help in cases where you do have classes with custom move assignment / construction / destructors, and by definition we end up with the behavior outlined in this video. It doesn't change your point, but there are a lot of cases with default constructors that the simplified code will run just fine with no additional overhead.

I don't think that calling a move constructor once is worse, than throwing an exception. Move constructor or operator= by their intent should be lightweight. This situation however is not great, but neither as bas as you describe it.

Great episode!

Quite frankly, if it comes to exceptions, I use them for truly exceptional things. But errors are not necessarily exceptional. In quite some cases they are even expected (or at least something which you SHOULD expect). And exceptions are ergonomically REALLY stupid for that and express the intent just way worse than something like std::expected. Disconnecting the "happy" and the "error" path is not always the good thing to do. And expressing programmer intent in code is for 99% of code more important than efficiency, at least imo.

It was probably a mistake to make these part of the standard library, instead of language features. Interesting to see if anyone comes up with a workaround.

Great video. It's weird that the explicit vs non-explicit constructors seem to be reversed, we can't just write `return {std::in_place, 1};` for best results, but writing `return Lifetime{1}` is allowed and does the wrong thing. I am curious what the committee reasoning is for this strange behavior, I guess maybe they were worried about if the wrapped type also took `std::in_place`

well, to be honest I always use optional / variant as a way to return when exceptions is not needed, but code can still fail. but I don't mark the parameter as explicit as those error structs that I use are only used in this context. so no issue for me, but still interesting!

This strikes me as something that could potentially have been dealt with via a more explicit Some(foo) and None design for these container types, but I haven't thought through it to pick out whether that's true.

I loved the end! Makes me subscribe.

Therefore forcing to explicitly construct objects (as convention) can prevent many of this kind of errors?

I find it interesting that, at 6:48, if you had used an auto return type you would've gotten the behavior you're looking for just coincidentally. Dunno if that's a meaningful observation but I think it makes me want to keep using auto, especially since I don't want to unnecessarily type the return type twice personally.

Would love if you could make a video on book recommendations for C++ in 2024

Is there a compiler flag to get a warning for these scenarios?

I run into a situation where I want to be able to return a struct wrapped with std::expected and initialize it with designated initializers but it's just impossible to do that and avoid copy or move. I just hope the compiler is smart and can optimize it.

I wonder how hard it would be for a compiler to implement a flag that explicitly says you want implicit conversions to standard library containers to fail when it would force an extra object. Obviously that wouldn't be standard compliant behavior, but that's the point of it being a flag (just like -fno-exceptions or -fno-rtti).

I guess this is what make_optional and the like are here for Just a shame theyre annoying to use because of just the way they look and also giving you horrible compiler errors when the ctor signature changes

What annoys me the most is that when using the make_ family of functions to create the object in place, you can't do aggregate initialization anymore... Nevermind the C++ designated initializers.

If you didn't have the operations being performed in the various constructors, would the compilers be able to optimize those operations away?

This episode makes me feel better about my rampant use of raw pointers

Would using some helper function, like make_optional, or make_expected fix this?

Wouldn't make_optional() be a better option?

With expected is even worse! I'm using a static std::expected to construct my object, and having a private constructor, but this blocks me from passing std::in_place + Args, as the constructor is private... How can I apply rvo in this case? will "return std::expected(Class(args)); " work? I tried this and it called the move ctor...

Btw, RVO is still working! After all, the return value is not copied. What is copied/moved is the thing that belong into the return value. To say that RVO is disabled in these cases is wrong. But overall, you are not wrong with the video. It is not zero-cost abstraction if the actual use-case (and intended use) is not zero overhead. These features basically violate c++.

If everyone is using it wrong, what does that say about the language

Why there are no `make_optional`, `make_variant`, `make_expected`, `make_unexpected` factory functions? Just like `make_pair`. Function template argument deduction would kick in and I need to write less template stuff. Or is CTAD solving this? Or is thiss non-issue to begin with?

This is a pretty annoying and significant limitation :(. Accidentally calling copy constructors is one of the major pitfalls of c++

What happened to good defaults?

6:38 the constructor taking std::inplace_t should also be conditionally explicit. It's tedious to write the whole type name. I usually prefer just returning the value_type of optional but as this video suggests, it might not be as optimal. So std::inplace_t constructor should be used for "non-trivial" value_types but that constructor shouldn't really be explicit.

I am curious whether we can apply the concept to a function that works with some lvalue. For instance assume we have this code : std::optional findUser(const std::vector& users, int id) { for (auto& user : users) { if (user.id == id) { return user; } } return std::nullopt; } Would it be more optimal to write : std::optional findUser(const std::vector& users, int id) { for (auto& user : users) { if (user.id == id) { return std::optional(user); // Constructing optional directly } } return std::nullopt; }

Cannot be catch using static analysis like a rule for clang-tidy?

Couldn't you just write `return {Lifetime(42)}`? Same for the std::expected case, just braces around `l` should work?

Couldn't RVO be generalized to handle these cases with "nested" types? Not changing how i use optional etc. it's not worth it except in very rare cases.

This really does seem like a language defect. I haven't looked through the papers for these facilities yet but surely they must have at least thought about this issue? There must have been some way that would not have made this an issue even if it qould have required more involved changes

Oh dear.. that *is* quite unfortunate.

I learned something ! Again ! Although not sure I'll ever use it. Am I a bad C++ programmer for avoiding std:: as often as I can ? I place clarity and readability of code over anything else. "Ce que l’on conçoit bien s’énonce clairement. Et les mots pour le dire arrivent aisément" And I never felt any clarity in the use of std:: or the huge error cascades that are (were now days isn't it ?) generated when compiling typos.

I wonder if there are similar problems in Rust

I do regret watching this episode.

std::make_expected

This is the kind of stuff that makes one look for alternatives to c++ or even become a humble avocado farmer instead.

Interesting issue. How about declaring the return object as "decltype(*this)"?

Are you 100% certain sure that the print() function isn't making the compiler opting out of optimizations due to unoptimizable side effects?

Thanks for this insightful episode. Whenever I want to like C++, they‘re doing something like that. 😢

4:30 - return 42

What a mess

why did you return {42} and not just 42? same for expected just do a if (foo) return 42; else return "not foo"; should work and call the right constructor of explicit (once)

That’s crazy

Regretted watching this, hahaha

This is one of the things that I've always hated about C++ and that I've hopefully made better in my own language with more inference. I guess you could say in my language I infer all the things.

Yeah... I do regret watching this video. I went from, oh interesting, oh do I have problems I need to fix now? to oh wait... no, implicit brace initialization works, he had to make it explicit for it to not work... so... I think we are fine? Wait... what did I learn from this? I guess I gained worry that I am missing something?

No, I'm not.

That's why any serious library or project are written in C, not C++. You cannot expect what instructions compiler will generate without going insane with C++

This language is insane lol

Virgin std::variant fan vs Chad void* + c-style cast enjoyer