0:00 / 0:00
- Recommended by 1 person: 1 on Lobsters.
- Presented by Logan Smith
- An opinion. It argues one side of a question engineers disagree on.
Advanced. Deep dive for people who know the field.
56K views12 months ago1 recommendation
Programming languagesSystems programmingC++Memory management
Logan Smith argues that C++'s implementation of move semantics, which leaves behind empty moved-from objects, harms performance and simplicity.
Move semantics are about quickly relocating your objects to new places in memory with all their invariants intact... but I argue that C++'s version of move semantics, which leave behind an "empty" moved-from object, ends up harmful to your code's performance, simplicity, and robustness. I made this video about ten months ago and promptly forgot about it. Here it is, a bit belated. Some random remarks: - I know that std::optional of T& is largely hard because of assignment, and I know that the real source of the issue is that T& is weird. ("References Are Broken" video when?) In my current codebase at [employer], we have an `optional_ref` template that is quite nice to use and doesn't have so many subtle head scratchers, because it is not trying to BE a specialization of `optional`, so it can deviate from `optional` when there isn't a clear answer. Representation-wise, it's just a pointer. - I forgot to mention, the default constructor of TSharedRef, which isn't supposed to exist in the first place, actually triggers a fatal error if it gets called. That's so bad. Code that is unconditionally incorrect should not compile. Researchers are saying that that's actually the whole purpose of the compiler/type system. - The performance cost of converting the TSharedRef returned by MakeShared into TSharedPtr is most likely not going to be a real problem compared to the memory allocation in MakeShared, especially because the control block will be in cache (having just been created). Just take this point as mildly interesting and illustrative of a possible pitfall when "upcasting" a prvalue of a non-movable type. - Even though it's not movable, I still do really like an optional scoped_lock as opposed to unique_lock. I want to wrap "but maybe not" _around_ my types, rather than bake it in. - I know that the template specialization syntax for folly::IsRelocatable at the end is wrong, but, that's how it's written in their official documentation! Go look it up! (Thanks for watching that far into the video.) Thumbnail by Michelle Lee. michellemlee.com I use the amazing Manim library for animating these videos, and I edit them with Blender (isn't that weird?) and Audacity (the program and sometimes the concept). manim.community/ blender.org/ audacityteam.org/Why it's here
1 person recommends thisWhat people say. Recommended as an excellent critique of C++ move semantics and their impact on code safety and performance.