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

---

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.
---

---

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.
Video Sponsors: millennium and think-cell
---

---

#boost #cpp #cppprogramming #cplusplus #softwaredeveloper

[roikadmon]

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

[wissensfrosch]

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

[_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!

[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.

[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.

[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.

[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.

[mytech]

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

[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.

[rinket]

This didn't age well - google just demonstrated you can REMOVE some UB and add bounds checking to container accesses and incur hardly any penalty.

[Heater-v..]

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.

[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]

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++.

[todortotev]

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.

[mastermati]

Isn’t it reupload but with corrected slides?

[tommasochiti]

I hate it when moments like 7:20 happen, is it really necessary to stop the host to make a comment just to show off you knowledge? C'mon this is high school behaviour..

[AlfredoCorrea]

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

[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.

[romanzelenyi]

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.