Thread by @meetingcpp

Yes, you can't really rely on the debugger as your major dev tool for Modern C++.
But Modern C++ does not stem from that school of thought, that the debugger should be a major dev tool... #LastRT

Well, seems that tweet needs some context.
Its a reaction and reflection on this blog post: aras-p.info/blog/2018/12/2…
Specificly on the debugging parts and performance of non release builds.
Also its wording isn't perfect, so lets get into the details with a thread.

First, I don't say that you shouldn't use a debugger. You can with Modern C++, its just not the best combination, as performance in non optimized builds is not always where Modern C++ shines. But that hasn't hindered this part of the language to flourish.

boost is hated but also successful as an example. And the newer Standards took a lot from boost into the library.
And with the new Standards lots of code is written with Modern C++ in mind. CppCon, C++Now, Meeting C++ and other conferences are full of examples.

And with debugging, Modern C++ takes the stance that you can now what the code does, without running it through a debugger first. Its heavily build on reliance on the type system, and constexpr/TMP to validate during compile time.

So, there is an argument to be made, that many bugs can be caught before you need a debugger to find them at runtime. Prevent misuse of APIs, use RAII and other basic C++ idioms.

So, there is not such a big penalty, when you need to debug, as its rare. Modern C++ did in some parts trade debug speed for reducing general error likeliness in code. Preventing bugs with the type system, RAII and compile time checks.

And in the recent years to this has been added tests and sanitizers and tools like clang tidy, google benchmark, perf. A large set of tools, helping to catch even more bugs.
The thing they can't catch though is human error.

All of this works very nicely, when your code base is mostly modern C++, which it might not be if you're in the games industry. Then of course the debugger is an important every day tool.

And I think, that there needs to be also a bit more focus on tooling and maintainability for C++ in the committee. And with SG15, there is a beginning:
isocpp.org/std/the-commit…
I do think that @TitusWinters is happy about any participation.

The ISO C++ committee is where the future of the C++ standard is made. If you're in Europe, this year will see meetings of the committee, in Summer in Cologne, and in Fall in Belfast. There is also an earlier meeting in Hawaii in February.

Now to the school of thought part, when you read the above, thats how I see modern C++ in its relation to debugging, and why the slow performance of non optimized builds hasn't hindered its evolution at all.

But I've also spend the last 7 years with not only writing code, but also doing work for the C++ Community. I've organized Meeting C++ as a yearly conference 7 times, been to all CppCons and C++Now. So I do have some fair share of insights and lots of seen talks.

And Modern C++ has been popular through out this time, and C++11 to 20 are build on this. Also talks on maintenance or application programming are rare. In submissions and approval through the program committees.

So maybe thats something where the industry and the language/library building community need to have an exchange. Which is the good thing I see in these debates which the blog post and my tweet spawned.