This is C++: Uncompromised Performance, Undefined Behavior, & Move Semantics - Jon Kalb C++Now 2024

www.cppnow.org​
---
This is C++: Uncompromised Performance, Undefined Behavior, and Move Semantics - Jon Kalb - C++Now 2024
---
The mandate for C++ is to deliver uncompromised performance and leave no room for a lower level language.
This presentation looks at C++’s superpower for delivering on this mandate. We explore this both to understand how to write better C++ code and to better understand how to evolve C++.
We’ll look at several examples showing how this superpower is applied in different ways, including one of the most controversial issues facing the C++ community today.
---
Slides: github.com/boo...
Sponsored by Undo: Debug your hardest C++ bugs with time travel debugging → Learn more at bit.ly/cppnow24
---
Jon Kalb
Jon Kalb is using his decades of software engineering experience and knowledge about C++ to make other people better software engineers. He trains experienced software engineers to be better programmers. He presents at and helps run technical conferences and local user groups.
Jon is passionate about quality code and wants to inspire others to achieve their best engineering work. He is excited about modern C++ and how we can exploit the latest hardware developments with standard, portable C++.
---
C++Now 2025 - 28th April - 2nd May
C++Now is an annual onsite international C++ programming and coding conference held in Aspen, Colarado. For all C++ developers, C++ software engineers and those involved with the C++ language, CppNow provides an indepth and technical content provided by the best and brightest C++ experts of the C++ world.
Annual CppNow Conference - www.cppnow.org
/ cppnow​
/ cppnow
/ cppnow
/ cppnow
mastodon.socia...
Video Sponsors: millennium and think-cell
---
Videos Filmed & Edited By Bash Films: bashfilms.com/
KZbin Channel Managed & Optimized By Digital Medium Ltd: events.digital...
---
#boost #cpp #cppprogramming #cplusplus #softwaredeveloper

[@wissensfrosch]

The talk is much better with the synchronized slides. Thank you C++Now for uploading this fixed version of the video.

[@BoostCon]

Thank you!

[@tal500]

That was a very good talk!

[@jonkalb2746]

Thanks for your kind words.

[@roikadmon7093]

Thank you for reuploading the video with the slide timings fixed! I found this talk to be quite insightful.

[@BoostCon]

So very pleased to hear that you found this talk to be informative. Thank you for your comment which is much appreciated!

[@jonkalb2746]

Thanks for your kind words.

[@kyber.octopus]

Amazing lecture / talk. Honestly i had no idea that these were design choices. Maybe i should blame the university lecturers, or myself. Always seemed like the language was simply unfinished.

[@jonkalb2746]

Thanks for your kind words. No language which is in widespread industry use is ever finished.

[@_noisecode]

Thank you so much for the re-upload!! I was so interested in this talk but it was hard to watch with the slides being out of sync. Can’t wait to dive in!

[@_noisecode]

Update: great talk. Jon hits on a friction with move semantics and weakening invariants that has bothered me for a long time, and his arguments about the requirements on moved-from objects are well-articulated. I have to think destructive move (relocate) would basically fix things here. If a moved-from object simply no longer exists, we don’t have to spend any time reasoning about or maintaining its state, either as class authors or class users.

[@BoostCon]

Yes, the out of sync version was a difficult watch! Thank you so much for your appreciation of the re-upload!

[@jonkalb2746]

@@_noisecode Thanks for your kind words. I think the issue with what you are suggesting is that we often want to move from objects to which we want to (later) assign a new value. This is important for swapping, sorting, and any number of valuable algorithms. Consider an element in a container. If moving from that object makes the object no longer exist, what does this mean for the container. It now holds an element that no longer exists, but the container has no way of knowing that (because we can move from objects without notifying that container that holds them).

[@mytech6779]

Thanks for the re-upload. Poor alignment of slides to speech boundaries can be a big hit on communication efficiency.

[@BoostCon]

Thanks to you and all others who commented on the problem with the original version of Jon Kalb's presentation.

[@Roibarkan]

1:14:18 Safety keynote from C++Now 2023: kzbin.info/www/bejne/fZmaaqqZfK-Xisk Safety panel from C++Now 2023: kzbin.info/www/bejne/oHfMZpZ_gc-Vd5Y

[@RicardoCapurro]

Congratulations!! Very interesting exposition about the burden introduced with move semantics on RAII and lifetime of objects, years ago when studying this I realized the same problems, and I concur it is a pity this had been implemented this way. Let's see if for cpp2 Herb fixes this problem, since function constructors are a great oportunity to consider moving to destruct the object and fix once and for always this problem.

[@jonkalb2746]

Thanks for your kind words. We’ll have to see where cpp2 ends up.

[@JudgeFredd]

Very very interesting !

[@muzikleringucu]

Thanks for the talks but I don't agree some parts. 1. compilers are optimized out ub not because they can but because the standards allows. So that means that compiler does know what is ub or not. So either compiler can generate error for that or the as-if rule should be updated so that the compilers cannot optimize out the ub. In ideal world, ub doesn't happen but it is not an ideal world. There will be ub code. to optimize out these parts can create hidden bugs which is causes a lot of issue. 2. UB is not a some hidden power, it is actually weaknesses of the C++. Especially not so senior developers. For the ideal language, they may be unspecified behaviour which can be changed from environment to environment but there shouldn't be any undefined behaviour. There are couple of reasons for that. First, if all programmers will do the same thing to prevent the ub, then this ub should have some defined variables. Think about uninitialized variable cases. if a variable is not initialize -> it can be optimized out -> so there should not be any uninitialized variable -> so all programmers must initialize these variables. If all programmers somewhat initialize any variables, then it is logical to add zero initialization. Second, UB sometimes create hidden bugs. I understand that there should be some unit test, etc but again, we are not an ideal world. And as you mentioned in memory safe language, "the believe that the use of memory safe language create buggy application and kills the people". This argument is also valid for UB. so why we have UB then? One possible answer is that the program should have unit test/static analyzer to prevent ub. then the same argument is also applied in memory safe language. then why cpp doesn't have the memory safe feature? Did you get it?

[@CuriousCauliflowerX]

As someone who makes a living teaching C++ - there goes the conflict of interest. You can have performance-heavy options while making safe the default. But you can't acknowledge that because it's literally a challenge to your bottom line which depends on C++ being more complicated than it needs to be.

[@StefaNoneD]

He's basically listing many problems, that Rust solves. I.e., accessing a moved object, is not possible in Rust at compile time. Overflow, underflow and division by zero, is checked in Debug mode, but not in Release mode.

[@todortotev5399]

The amount of logical falacies used was ... beyond measurement. Java has been with us for 29 years and C# - 22 years. But, obviously, for C++ to have a chance, we must all forget about these completely unknown languages and ecosystems. Also, I winder, does the speaker uses safety belts in his car? They are proven to not work above some speeds, while preventing almost all injuries bellow t0 km/h. By his logic, they are completely useless because ... That's the C++ way. Also, the tooling outside of the C++ ecosystem is way way way way way better. Also, we know that we cannot know what "a+b" actually works. With the preprocessor, operator overloads, and sufficiently advanced template magic, "a+b" can launch a LLM, which generates a command in ancient Egyptian to a REST api of fhe USA military force fo launch a nuclear strike. Or, you know, add a and b. And of course, let's not forget that C++ is completely undeadable, and significant parts of a c++ program is not busy expressing business logic but placating the compiler or working around language deficiencies. std::move, anyone? In what sane language this is needed? And this unreadability hides bugs. And prevents creating actually working tools, such as the ones the memory safe languages have been enjoying for decades. And last but not least, the C++ compiler has been doing math and all sorts of magic calculations since forever, the idea that "it only cares about types" is blatantly false. But, again, unless we outright lie, we cannot weasel ourself out of the increadible badness of that cursed language.

[@flying-sheep]

8:08 “the index operator is unsafe because of performance […] in a loop you don’t need bounds checks”. But shouldn‘t one use iterators instead? then you’d have `vec[i]` being checked and slow, `vec.get_unchecked(i)` being verbose, fast, and unsafe, and iterators being fast, elegant, and safe.

[@Heater-v1.0.0]

Did it ever occur to anyone that automatically setting uninitialised variables to zero is no better than leaving as some random number or declaring that using it is UB? Compilers can detect this error at compile time. Why doesn't C++? For this reason, and many others, I will not be using C++ anymore. Because this is C++. By the way, I have never heard anyone who advocates using memory safe languages confusing memory safety with overall logic correctness of programs. They are not stupid. They welcome using static analysis as well. Static analysis is able to work far better when it can use the information provided by the source it is given, information that is missing from C++ source.

[@JohnDlugosz]

In C++26, compilers can detect it and warn you. Why didn't it? Because undefined behavior _in general_ is not something the compiler has to issue a diagnostic for. It was a case of "one size fits all". The compiler might detect it but rather than warning you, optimize the code out because this path (that produces undefined behavior) should never be taken. But seriously, why are you declaring your variables before they are ready to receive their initial value? Don't cluster than at the top -- put them at first use.

[@jonkalb2746]

@@JohnDlugosz Thanks for the comment. In particular advocating for the best practice of declaring variables at first use.

[@captainbanglawala2031]

There's always a speed vs safety trade off in any language. If you want bounds checking you must pay for it in CPU cycles. IMO, safety is more important than speed in most cases.

[@brunobignose]

This is absurd, seeing UB as the language’s super power is crazy when it is the thing that will ultimately destroy the language and cede the ground to Rust and other memory safe languages. The problem with C++ isn’t performance above safety, the problem is that there are no safe options easily available. For example, in many cases numerical overflow may not be a concern, but when it is, a huge burden is put on the developer to deal with it. Putting code in something like of ‘safe’ and ‘unsafe’ blocks allows the programmer to clearly indicate what they want and when they are willing to take the performance hit, this still sits with the zero overhead philosophy. Adopting easily opted-in/opted-out safety is as important as performance to the future of the language.

[@mastermati773]

Isn’t it reupload but with corrected slides?

[@vytah]

Yes. Because the original upload was unwatchable.

[@AlfredoCorrea]

1:01:02 clang tidy already warns against using moved-from objects. Even standard containers I think.

[@CuriousCauliflowerX]

Nondestructive move semantics chosen by C++ are not a performance improvement - they're a performance degradation that introduces unnecessary branching in the destructor code and redundant execution of destructor code because it has to execute for moved from objects even when there's nothing to destruct. It clearly violates the "performance above else" principle, rust's move semantics are more performant. It's very funny that C++ programmers became so deranged as to find themselves doing reassuring chants. "This is C++!". C++ doesn't have to care about safety. Programmers don't have to care about C++. You're free to stay in your bubble, just don't expect everybody else to also be a luddite. Just don't cry when your language can't be used anymore for safety-critical industries and applications. No more mars rovers in C++.

[@romanzelenyi982]

I cannot agree that the requirement for moved-from object to be in a valid state is a mistake. Otherwise the standard must define a new state of object. Also, moving operation can be conditional, so there must be a uniform way to detect that state. All this would bring more complexity to the core language, not just the standard library.

[@jonkalb2746]

@romanzeleny1982 Thanks for taking the time to watch the video. I don’t agree for all the reasons that I put in the video. Note that although it would be helpful for the standard to spell out what I advocate for in the video, it isn’t truly necessary. As long as the standard doesn’t get in the way, which seems to be its direction. It is true that moving may be conditional, but there is no situation where that is true that proper (non-logic error) code doesn’t just assume that the object is, in fact, moved from. This doesn’t add any complexity. The complexity is already there. The only question is do we write code that neither compromises performance nor contains logic errors.