Great talk Sean, as always. Thanks! 56:12 For anyone interested, the need to add 128 (instead of 127) is because the fast algorithm divides by 256 in the last line, instead of 255 (both the inner and outer division). The 128 is required to get these divisions to round correctly, specifically when ((a*b) % 256) = 128. In only these cases, the fast algorithm (using 127) would round down instead of up, and yield an incorrect result. When the fast algorithm uses 128, it rounds correctly in those cases.
Wonderful talk. I completely agree on using asserts and also making sure they don't change algo complexity. For developer time, it is one of the most efficient ways to (partially) verify correctness.
I'm starting to think Sean Parent is like this uncle of C++. Cool and knows all the stuff and is happy to teach. Honestly his points are good. A lot of languages are popping up that are successfully fixing a lot of C/C++ issues. Like the readability of the library and having some sort of teaching tools and exercises to learn to use the language. Or just good material on using the language over reading templated documentation that makes no sense. Languages like Rust and Zig, much, much faster, fixing safety/memory issues, having package managers, having learning tools, brilliant error messages from the compiler. Given that Rust has the con that C++ doesn't: getting the code to actually run is next to impossible, because it holds you responsible of doing it until it's right.
Performance certainly isn't the only reason for using C++. I've moved on to Rust now, but I built a very large personal C++ code base over the last couple decades (1M plus lines of code.) It covers a huge range of functionality, from a virtual kernel at the bottom (in terms of which everything else is written) all the way up to my own 'stand'ard' libraries, UI framework, multi-media, distributed processing framework, and much more using almost zero third party code so I have my own implementations of PNG, ZLib, XML, JSON, encryption algorithms, OO macro language with embedded VM engine and debugger, and many other things, and then there's a high end automation system (CQC) written on top of that general purpose layer, which is insanely complex. My system doesn't have massive performance requirements, but I needed at single language that could cover that whole range, and it couldn't be NON-performant either, so something garbage collected was out of the question. With C++ I just had to be reasonably cognizant of performance in order to end up with a system that performs very well and uses minimal CPU, despite being highly active, highly multi-threaded and distributed. I didn't have to do heroic amounts of optimization. There really wouldn't have been any other reasonable option until recent years. It couldn't be some obscure language that hardly anyone knew or that was on the way out. So C++ was the obvious choice. But, the complexity of something that broad and complex in C++ is just overwhelming. I developed mine under almost perfectly optimal circumstances, and it was a real challenge to keep it really tight over time. Under normal commercial software circumstances, it would be an order of magnitude worse probably. C++ just really isn't up to the task for that kind of thing anymore. I mean, it CAN be done. But the percentage of time and mental cycles that goes into just avoiding UB and memory issues has become too large and too dangerous. Though I HATE that Rust doesn't support implementation inheritance, and exceptions which I quite like, the safety guarantees and lack of UB is just too powerful a benefit to ignore. Now if someone came along with a full on OOP language that also supported the same guarantees, I'd be all over that. But, in the meantime, there's nothing else out there. For the kind of system I created above, it would be far easier to keep coherent over time and significant changes, and I could have spent far more time on what's important instead of being sure I wasn't shooting myself in the foot, and could have slept a lot more soundly. Now, C++ is pushing itself into a 'Performance Uber Alles' corner, that's just going to get smaller and smaller as we move forward. Not just because languages like Rust will get more efficient, but also (I hope) because more people realize that having one of the fundamental building blocks of our society be robust and secure is more important than it being 5% faster. Or, maybe not. Performance is an obsession in C++ world these days, and people will actually argue you down that it's better to be fast than provably safe or correct.
Very interesting your opinion about Rust. In addition to implementation inheritance I am missing a less restrictive reference handling. I am currently looking into Pony language (after considering cpp, go, Rust, Scala, kotlin, vala, Crystal and more) as an alternative to Java for application development. Unfortunately, Pony also followed the tide regarding "impl inheritance is bad", but they have builtin actors, a reference concept, which still allows the "unfashionable" OO "sea of objects designs", traits with protected methods (strategy patterns?!!), no exceptions, no UB, compiles to binary via C/interfaces to C and more. Small ecosystem, but very promising, at least as a study, what's possible.
Hi Dean, nice detailed comment! There is something i can't get though. At the end of the day, is C++ worth or not?? Because the middle third principle holds here: either C++ is worth and is "the" choice, or it is not. It's not possible to stay in between. Staying in between doesn't give the opportunity to focus on another new language completely: language X would be the choice, but unfortunately has drawbacks 1,2,3.. If you decide to violate the middle third principle, then please suggest a solution that satisfy the simultaneous existence of competing languages. Something that helps change something for good.
Thank you for the sharing the experience, Rust indeed looks great, however it is not friendly for the newcomers expressing some familiar idioms, e.g. self referential or mutually referential obrects.
@@linkernick5379 Rust newcomer and C++ novice here, I actually strongly prefer Rust because of the safety, tooling, error messages and find it all around just so much easier to get working code. For example, I wrote a raytracer for a university project in C++ 15 years ago with OpenGL for Windows, and I rewrote it in Rust but never got it to work in C++ again as I changed from header files to modules but those didn't work correctly in gcc. Maybe I will try it again 15 years from now. I still couldn't write a linked list in Rust but I never needed that until now.
I'm kind on on similar boat with the bag-of-tricks libraries I have built up over the years. Is any of this stuff available somewhere, or just private stash?
23:30 Actually, those additional lines of code are likely bug fixes, not due to the increasingly complicated language. Search for "c++ empty pair base".
@@ChrisM541 In the way that you can't access 99% of the computing power of the system with them (unless using GPGPU APIs): yes, they are just "scripting" the slower CPU, without touching the GPU, which has almost all the computing capability of the system.
So my take away from all this is that C++ has an ugly syntax, C++ is overly complex, C++ is not safe in anyway. Likely none of this can be fixed. Makes me feel OK that after decades of using C++ I gave up in disgust a few years ago and moved on. It's good to know smarter people than me feel the same.
37:58 Is safety really transitive? Each of these operations are safe on their own: fork(), read(), write(), but when combined in a certain order, they cause data-races and, hence, undefined behavior. I feel safety is not-transitive, much like correctness. What am missing here?
Neither read nor write are safe, since as you say, if the preconditions are not met you can cause undefined behavior (I don’t know about fork tbh). A safe operation would be, for example, an add function for two integers that would wrap on overflow.
referencing ua-cam.com/video/kZCPURMH744/v-deo.html First, he means that signed integer overflow is undefined. Second, even if it was defined, it would still be confusing for an average developer. For example, overflow is defined for unsigned numbers. Speaker is probably using "Modulo two" to refer to the below behavior which simply means "wrapping around" for us normal people. (Paragraph 3.9.1/4): Unsigned integers, declared unsigned, shall obey the laws of arithmetic modulo 2^n where n is the number of bits in the value representation of that particular size of integer
36:26 'operation is 'safe' even if preconditions are violated' What means SAFE in reality? For example, sort. Its impossible to check in this universe(so much time to solve this) is predicate is valid. You can guarantee, that it will not cause segfault, but is this safety? NO. Your code has invariant - this shit is SORTED. But it is not sorted in reality. It can (and will) cause worse bugs than just crashing the app due to a segfault. A logical error in calculating where to turn is much more dangerous for a car than writing to a random place in memory, after which the program will almost certainly stop executing. "pretend" that everything is fine and the sorting was completed successfully is NOT safe. It's even more dangerous than just doing anything. This is very similar to hiding problems from management until things go too far.
Of course, even if you know the code is memory safe (free from UB), you still to verify somehow that it does what it's supposed to-probably with some combination of testing and static analysis techniques. But if the code is not memory safe, then you cannot rely on your tests or static analysis in the first place. It doesn't matter that your sorting function is logically correct if a use-after-free somewhere else in the program has corrupted its inputs-the car will still crash. Memory safety by itself is not enough, but it's the foundation that everything else builds upon. Without it, the whole edifice collapses.
@@Snarwin I think the point is that the build chain should make it easy to write provably correct code, as when it does all that memory safety stuff is irrelevant -- the sorted buffer is only unsorted because of a cosmic ray, not because there is rampaging code somewhere else overwriting memory, because at the end of the day the kernel can always do rampaging and can even ignore the segfaults that you wanted it to generate for you.
At 22:00 I have to question the sanity of a person who writes (or rather generates) such code and calls it a feature of a modern language. If you can't do it in C, you're simply doing it wrong 😉
I don't know if he's trying to sensationalize this talk or if he's received brain damage in the past couple of years, but there are several "points" he makes that are just wrong. For starters, outside of niche mathematical uses, overflow isn't a problem, and in those instances where it could be a problem you can detect overflow yourself before causing it and thus prevent even the possibility of ill effects. Part of the problem I see relating to it is people not checking user input, and if you're not checking user input then you probably shouldn't be a programmer. As far as sorting floating point data, you can provide your own comparator if you don't like what the default does, but there's nothing in the standard preventing you from calling std::sort() on such arrays. And I'm going to skip all the rest to say that no language should have an unsafe keyword. That's the kind of garbage that gives newbies a false sense of security which causes even worse subtle bugs to crop up. No programming language should constrain programmers like that. Far too many new languages keep popping up that constrain you in ways that prevent valid use cases and try to push this propaganda that it's justified because it prevents bad programs, even though there are whole classes of problems that they do nothing to prevent and which can be far more pernicious than the classes of problems they do prevent. But ultimately, if you want to constrain code that scares you into "unsafe" sections, use a static analyzer, as there are many to pick from, including free and open source analyzers, and just add a comment around that code labeling it unsafe.
A new Sean Parent video just dropped. My first thought? "I wonder how many new things I'll discover were really just rotations all along."
Great talk Sean, as always. Thanks!
56:12 For anyone interested, the need to add 128 (instead of 127) is because the fast algorithm divides by 256 in the last line, instead of 255 (both the inner and outer division).
The 128 is required to get these divisions to round correctly, specifically when ((a*b) % 256) = 128. In only these cases, the fast algorithm (using 127) would round down instead of up, and yield an incorrect result. When the fast algorithm uses 128, it rounds correctly in those cases.
Wonderful talk. I completely agree on using asserts and also making sure they don't change algo complexity. For developer time, it is one of the most efficient ways to (partially) verify correctness.
As a co-creator of bool, I appreciate your story about std::pair. Personally I have been selective in adopting new features of the C++ language.
I'm starting to think Sean Parent is like this uncle of C++. Cool and knows all the stuff and is happy to teach. Honestly his points are good. A lot of languages are popping up that are successfully fixing a lot of C/C++ issues. Like the readability of the library and having some sort of teaching tools and exercises to learn to use the language. Or just good material on using the language over reading templated documentation that makes no sense.
Languages like Rust and Zig, much, much faster, fixing safety/memory issues, having package managers, having learning tools, brilliant error messages from the compiler. Given that Rust has the con that C++ doesn't: getting the code to actually run is next to impossible, because it holds you responsible of doing it until it's right.
This talk was so intimidatingly mind-blowingly awesome... Totally didn't expect it to be so interesting!
superb talk !!
Performance certainly isn't the only reason for using C++. I've moved on to Rust now, but I built a very large personal C++ code base over the last couple decades (1M plus lines of code.) It covers a huge range of functionality, from a virtual kernel at the bottom (in terms of which everything else is written) all the way up to my own 'stand'ard' libraries, UI framework, multi-media, distributed processing framework, and much more using almost zero third party code so I have my own implementations of PNG, ZLib, XML, JSON, encryption algorithms, OO macro language with embedded VM engine and debugger, and many other things, and then there's a high end automation system (CQC) written on top of that general purpose layer, which is insanely complex.
My system doesn't have massive performance requirements, but I needed at single language that could cover that whole range, and it couldn't be NON-performant either, so something garbage collected was out of the question. With C++ I just had to be reasonably cognizant of performance in order to end up with a system that performs very well and uses minimal CPU, despite being highly active, highly multi-threaded and distributed. I didn't have to do heroic amounts of optimization.
There really wouldn't have been any other reasonable option until recent years. It couldn't be some obscure language that hardly anyone knew or that was on the way out. So C++ was the obvious choice.
But, the complexity of something that broad and complex in C++ is just overwhelming. I developed mine under almost perfectly optimal circumstances, and it was a real challenge to keep it really tight over time. Under normal commercial software circumstances, it would be an order of magnitude worse probably. C++ just really isn't up to the task for that kind of thing anymore. I mean, it CAN be done. But the percentage of time and mental cycles that goes into just avoiding UB and memory issues has become too large and too dangerous.
Though I HATE that Rust doesn't support implementation inheritance, and exceptions which I quite like, the safety guarantees and lack of UB is just too powerful a benefit to ignore. Now if someone came along with a full on OOP language that also supported the same guarantees, I'd be all over that. But, in the meantime, there's nothing else out there. For the kind of system I created above, it would be far easier to keep coherent over time and significant changes, and I could have spent far more time on what's important instead of being sure I wasn't shooting myself in the foot, and could have slept a lot more soundly.
Now, C++ is pushing itself into a 'Performance Uber Alles' corner, that's just going to get smaller and smaller as we move forward. Not just because languages like Rust will get more efficient, but also (I hope) because more people realize that having one of the fundamental building blocks of our society be robust and secure is more important than it being 5% faster. Or, maybe not. Performance is an obsession in C++ world these days, and people will actually argue you down that it's better to be fast than provably safe or correct.
Very interesting your opinion about Rust. In addition to implementation inheritance I am missing a less restrictive reference handling. I am currently looking into Pony language (after considering cpp, go, Rust, Scala, kotlin, vala, Crystal and more) as an alternative to Java for application development. Unfortunately, Pony also followed the tide regarding "impl inheritance is bad", but they have builtin actors, a reference concept, which still allows the "unfashionable" OO "sea of objects designs", traits with protected methods (strategy patterns?!!), no exceptions, no UB, compiles to binary via C/interfaces to C and more. Small ecosystem, but very promising, at least as a study, what's possible.
Hi Dean, nice detailed comment!
There is something i can't get though. At the end of the day, is C++ worth or not?? Because the middle third principle holds here: either C++ is worth and is "the" choice, or it is not. It's not possible to stay in between.
Staying in between doesn't give the opportunity to focus on another new language completely: language X would be the choice, but unfortunately has drawbacks 1,2,3..
If you decide to violate the middle third principle, then please suggest a solution that satisfy the simultaneous existence of competing languages. Something that helps change something for good.
Thank you for the sharing the experience, Rust indeed looks great, however it is not friendly for the newcomers expressing some familiar idioms, e.g. self referential or mutually referential obrects.
@@linkernick5379 Rust newcomer and C++ novice here, I actually strongly prefer Rust because of the safety, tooling, error messages and find it all around just so much easier to get working code. For example, I wrote a raytracer for a university project in C++ 15 years ago with OpenGL for Windows, and I rewrote it in Rust but never got it to work in C++ again as I changed from header files to modules but those didn't work correctly in gcc. Maybe I will try it again 15 years from now. I still couldn't write a linked list in Rust but I never needed that until now.
I'm kind on on similar boat with the bag-of-tricks libraries I have built up over the years. Is any of this stuff available somewhere, or just private stash?
23:30 Actually, those additional lines of code are likely bug fixes, not due to the increasingly complicated language. Search for "c++ empty pair base".
Great cliffbanger.. Nick DeMarco is #Sharp😂😂
1:02:15 "C++ is just a scripting system."
Wow. That is a harsh dunk, but justified.
...in the 'same' way assembly language...machine code...microcode are 'just' scripting systems?
@@ChrisM541 In the way that you can't access 99% of the computing power of the system with them (unless using GPGPU APIs): yes, they are just "scripting" the slower CPU, without touching the GPU, which has almost all the computing capability of the system.
Thought provoking talk
Sean thanks for sharing the wisdom of ttime and experience in this excellent talk.
"The standard doesn't technically let me call std::sort() on floating numbers." 33:11 😱😱😱🙀
Does spec has examples? If yes, are examples considered as "comments" in spec?
The Val language is *THE* most interesting "C++ thing" this year. Check it out guys.
Very Interesting talk, I’m not the mathematician but you seemed to be taking to task the chip companies and or some versions of c++.
very interesting, thanks
So my take away from all this is that C++ has an ugly syntax, C++ is overly complex, C++ is not safe in anyway. Likely none of this can be fixed. Makes me feel OK that after decades of using C++ I gave up in disgust a few years ago and moved on. It's good to know smarter people than me feel the same.
cppcon has become a bit too spectacle oriented, quasi-political in a sense. I'm liking these talks.
34:55 most important statement of the whole talk? Because so much other stuff follows from this seemingly innocuous statement.
Would ISPC be a solution for your example of vectorizing scalar code?
didn't know about ispc, seems cool, thx.
37:58 Is safety really transitive? Each of these operations are safe on their own: fork(), read(), write(), but when combined in a certain order, they cause data-races and, hence, undefined behavior.
I feel safety is not-transitive, much like correctness.
What am missing here?
Neither read nor write are safe, since as you say, if the preconditions are not met you can cause undefined behavior (I don’t know about fork tbh). A safe operation would be, for example, an add function for two integers that would wrap on overflow.
"modulo two". You keep using that phrase. I do not think it means what you think it means. I think, from context, you mean "two's complement".
referencing ua-cam.com/video/kZCPURMH744/v-deo.html
First, he means that signed integer overflow is undefined.
Second, even if it was defined, it would still be confusing for an average developer. For example, overflow is defined for unsigned numbers. Speaker is probably using "Modulo two" to refer to the below behavior which simply means "wrapping around" for us normal people.
(Paragraph 3.9.1/4):
Unsigned integers, declared unsigned, shall obey the laws of arithmetic modulo 2^n where n is the number of bits in the value representation of that particular size of integer
The std library was never an example. C++ syntax is a work of art, std library isn't.
36:26 'operation is 'safe' even if preconditions are violated'
What means SAFE in reality? For example, sort.
Its impossible to check in this universe(so much time to solve this) is predicate is valid.
You can guarantee, that it will not cause segfault, but is this safety? NO. Your code has invariant - this shit is SORTED. But it is not sorted in reality.
It can (and will) cause worse bugs than just crashing the app due to a segfault. A logical error in calculating where to turn is much more dangerous for a car than writing to a random place in memory, after which the program will almost certainly stop executing.
"pretend" that everything is fine and the sorting was completed successfully is NOT safe. It's even more dangerous than just doing anything. This is very similar to hiding problems from management until things go too far.
Of course, even if you know the code is memory safe (free from UB), you still to verify somehow that it does what it's supposed to-probably with some combination of testing and static analysis techniques.
But if the code is not memory safe, then you cannot rely on your tests or static analysis in the first place. It doesn't matter that your sorting function is logically correct if a use-after-free somewhere else in the program has corrupted its inputs-the car will still crash.
Memory safety by itself is not enough, but it's the foundation that everything else builds upon. Without it, the whole edifice collapses.
@@Snarwin I think the point is that the build chain should make it easy to write provably correct code, as when it does all that memory safety stuff is irrelevant -- the sorted buffer is only unsorted because of a cosmic ray, not because there is rampaging code somewhere else overwriting memory, because at the end of the day the kernel can always do rampaging and can even ignore the segfaults that you wanted it to generate for you.
At 22:00 I have to question the sanity of a person who writes (or rather generates) such code and calls it a feature of a modern language. If you can't do it in C, you're simply doing it wrong 😉
12:08
I don't know if he's trying to sensationalize this talk or if he's received brain damage in the past couple of years, but there are several "points" he makes that are just wrong. For starters, outside of niche mathematical uses, overflow isn't a problem, and in those instances where it could be a problem you can detect overflow yourself before causing it and thus prevent even the possibility of ill effects. Part of the problem I see relating to it is people not checking user input, and if you're not checking user input then you probably shouldn't be a programmer. As far as sorting floating point data, you can provide your own comparator if you don't like what the default does, but there's nothing in the standard preventing you from calling std::sort() on such arrays.
And I'm going to skip all the rest to say that no language should have an unsafe keyword. That's the kind of garbage that gives newbies a false sense of security which causes even worse subtle bugs to crop up. No programming language should constrain programmers like that. Far too many new languages keep popping up that constrain you in ways that prevent valid use cases and try to push this propaganda that it's justified because it prevents bad programs, even though there are whole classes of problems that they do nothing to prevent and which can be far more pernicious than the classes of problems they do prevent. But ultimately, if you want to constrain code that scares you into "unsafe" sections, use a static analyzer, as there are many to pick from, including free and open source analyzers, and just add a comment around that code labeling it unsafe.