Do you mean "C++ in Constrained Environments"? Honestly, to me it feels very abstract and hand-wavy, lacking demonstration of a real-world problem being solved. It also looks like the same talk Stroustrup's been giving for the last several years, with maybe minor tweaks.
To me talks by practitioners, who have experience in a given field allowing them to know what works and what doesn't, are more compelling. In the past Mike Acton and Chandler Carruth were such speakers. After quickly going over the schedule, this year Ben Saks, Andrew Drakeford, Ivica Bogosavljevic, Eyal Zedaka, Daniel Withopf, Andreas Weis and Ilya Burylov seem to be such speakers. I'll watch their talks when they become available.
Yes it is the same talk, because too many keep writing C in C++, that is unavoidable when the language are 90% compatible at copy-paste level, people are stuck on their own ways without reason to upgrade themselves, and too many students still learn C++ the way it was taught pre-C++98.
Many of those practitioners, do indeed do great talks, but they also live in a bubble far away from 9-5 C++ coders that put out most code.
I advise a CppOnSea 2022 talk, "help me my team is stuck in 90's".
I am sure for many of those people, they do this because they have decided that sufficiently understanding the complexities of C++ provides too little payout (or in some cases none at all) to make the shift worthwhile for them. I don't think accusing developers of "being stuck in the 90's" is the right way to convince them to work differently. If the technology is actually better, you should convince them of such by demonstrating it with many concrete examples.
Contrary to what many seem to believe, just because something is new doesn't mean it is better, even when computers are involved.
> Maybe it’s time to stop blaming devs and instead blame the language?
Ah, blaming the tools: the Hallmark of a master.
Take a moment to think about the problem. You're in a multi-team project, with a few millions lines of code. You're paid to deliver results and meet the client's requirements, and you're already behind schedule. Suddenly the C++ standard committee releases a new C++ standard. What are you going to do? Are you going to
a) continue working on your tickets, or
b) are you going to drop everything to spend weeks updating tooling, projects, dependencies, and put up a series of workshops with the purpose of getting everyone onboard the new shiny toy?
And did you noticed that option b) adds absolutely no value at all?
It's great that you can flip a flag and turn your hello world project into a C++20 project with no work at all, but real world teams that are in the business of outputting real world production-ready code requires a bit more caution.
For instance, I still recall from a previous project I worked with how a n upgrade to C++14 led a dependency to over-eagerly jump head-on to constexpr which caused weird and non-trivial linking errors that took a week or so to sort out. And constexpr wasn't a new addition in C++14.
Upgrading to C++14 - a minor release compared to C++11 and C++17 - caused a weeksworth of weird, nontrivial linking errors.
Do you think that's an unavoidable law, or is it something accidental that could have gone better?
Would you say a similar minor upgrade of the language version in other languages would have also caused a week of similar hard to debug errors, for a project of the same size?
I'm curious who you blame, if you don't blame the tools. You could try to blame people. Or one might say it's just how things are and we can't do better.
I'm just not sure if you see this as unavoidable, or if it's something else that makes you say that? You got me curious.
> Do you think that's an unavoidable law, or is it something accidental that could have gone better?
It was the result of having to develop production code in the real world, reusing real world production code developed by third-parties.
In my particular case it just so happened that the upstream dependency exported interface headers that conditionally defined stuff with C++14 features in spite of what shipped with their binaries. Stuff using constexpr ultimately resulted in tons of hard to track linking errors.
> Would you say a similar minor upgrade of the language version in other languages would have also caused a week of similar hard to debug errors, for a project of the same size?
This was not a C++ problem. This was a problem caused by the way this particular project was designed to toggle C++14 features when they should not be toggled.
Just because problems emerge when updating a project to the next language version, that does not mean the language is held to blame.
This is one of the reasons why I firmly believe half the people in this thread talking crap about software updates and bumping programming language versions are quite frankly talking about stuff they know nothing about and have zero real world experience. There's far more stuff going on in a language upgrade than flipping a switch and rebuilding a project, specially if upstream dependencies made some less-than-advisable decisions on how to release their work.
So you were linking against prebuilt libraries, and you had third party headers for those libraries that were doing some constexpr stuff that was breaking linking because the prebuilts no longer matched the headers?
In C++ if you aren’t able to build your entire stack of dependencies from source you are gonna have a bad time like this at some point. Any prebuilt libraries you depend on better be pure C, headers included.
My experience with migrating real-world projects incrementally from C++98 -> C++20 has been that it is typically closer to a day of work to get everything working with the new standard, and that the benefits have been enormous. `if constexpr` is a particularly standout example of something which has turned things which would have been a week's worth from a C++ expert into something doable in an hour by a junior developer.
I am not surprised by this lack of understanding of human psychology. People will always do the most simple, natural thing that they learned at some point in their lives. You can't expect them to change overnight or even change at all.
A lot of folks who write C in C++ are old gurus who learned their trade long ago.
In the Q&As at the end Stroustrup does give us yet another version of the "We can just do that in C++" safety claim -- https://youtu.be/2BuJjaGuInI?t=4749
"I think that the approach I'm talking about with static analysis and rule based... for modern styles can deliver complete safety"
I expect over the next decade or so, a lot more resources will be thrown at unsuccessful attempts to solve this problem.
To me talks by practitioners, who have experience in a given field allowing them to know what works and what doesn't, are more compelling. In the past Mike Acton and Chandler Carruth were such speakers. After quickly going over the schedule, this year Ben Saks, Andrew Drakeford, Ivica Bogosavljevic, Eyal Zedaka, Daniel Withopf, Andreas Weis and Ilya Burylov seem to be such speakers. I'll watch their talks when they become available.