Agreed. As much as I want it to be simpler to build C++ programs from source, it's pretty much always _possible_ in my experience, it can just a PITA frequently.
I think that tests are a sure-fire way to improve the quality of your code, but I'd throw another piece in to the ring: sanitizers [0]. Projects that have good tests and run them regularly with TSan/ASan/UBSan in my experience are much better to work on because it means that it's much less likely there's deep seeded issues that are lurking. It gives you increased confidence that you're not introducing hard-to-detect issues as you go.
These tools aren't just exclusive to C++. I've said the same thing about C, Go, Zig, Odin, etc. Projects that use them (and have good automated tests) tend to be in good shape, and projects that don't tend to take a long time to make any progress on.
I've found compile times on large C++ code bases to be the only thing I really notice improving. I recently upgraded my work machine from a 2017 i7 to a shiny new Ryzen 9 9950x and my clean compile times went from 3.5 minutes to 15 seconds haha. When I compile with an M2 Max, it's about 30s, so decent for a laptop, but also it was 2x the price of my new desktop workstation.
I have poked around with Pernosco, and it's very impressive! I just added a paragraph to the intro of this series about it. Pernosco is so cool!
However, I think it's aiming to solve different bugs than I am usually after. I want a very quick-to-use debugger because I like to step through all my code as I'm writing it to sanity check. It generally just helps me stay focused and make fewer errors (I'm not the most detail-oriented person in the world, and the debugger helps keep me on the rails).
Pernosco/rr are invaluable tools for solving much tougher bugs, but I want a better debugger for the "every-day" sort of stuff as well. Thank you for pushing the state of the art though, Pernosco is jaw-dropping!
I agree with this whole thread. I do use VS Code as my debugger frontend for C++ on Linux, but it's a real bummer compared to what's available on Windows. Hence this series!
It was added well after GDB's design was set. Only when LLVM brought a permissively licensed competitor did the FSF start opening up its toolchain to not be left out in the race to the bottom.
I think that tests are a sure-fire way to improve the quality of your code, but I'd throw another piece in to the ring: sanitizers [0]. Projects that have good tests and run them regularly with TSan/ASan/UBSan in my experience are much better to work on because it means that it's much less likely there's deep seeded issues that are lurking. It gives you increased confidence that you're not introducing hard-to-detect issues as you go.
These tools aren't just exclusive to C++. I've said the same thing about C, Go, Zig, Odin, etc. Projects that use them (and have good automated tests) tend to be in good shape, and projects that don't tend to take a long time to make any progress on.
[0] https://github.com/google/sanitizers
reply