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.
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!
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.
@@_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).
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.
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.
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.
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.
@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.
The talk is much better with the synchronized slides. Thank you C++Now for uploading this fixed version of the video.
Thank you!
Thank you for reuploading the video with the slide timings fixed!
I found this talk to be quite insightful.
So very pleased to hear that you found this talk to be informative. Thank you for your comment which is much appreciated!
Thanks for your kind words.
That was a very good talk!
Very very interesting !
Thanks for the re-upload. Poor alignment of slides to speech boundaries can be a big hit on communication efficiency.
Thanks to you and all others who commented on the problem with the original version of Jon Kalb's presentation.
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.
Thanks for your kind words.
No language which is in widespread industry use is ever finished.
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!
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.
Yes, the out of sync version was a difficult watch! Thank you so much for your appreciation of the re-upload!
@@_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).
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.
Thanks for your kind words. We’ll have to see where cpp2 ends up.
1:14:18 Safety keynote from C++Now 2023: ruclips.net/video/Gh79wcGJdTg/видео.html
Safety panel from C++Now 2023: ruclips.net/video/jFi5cILjbA4/видео.html
Isn’t it reupload but with corrected slides?
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.
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.
@@JohnDlugosz Thanks for the comment. In particular advocating for the best practice of declaring variables at first use.
1:01:02 clang tidy already warns against using moved-from objects. Even standard containers I think.
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.
@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.