3 ms·
For what it counts, I have developed code for this kind of applications exclusively in C for ~5 years (let's say 20% of my working time). I still think that deb
by zanellia 5y ago
For what it counts, I have developed code for this kind of applications exclusively in C for ~5 years (let's say 20% of my working time). I still think that debugging a segfault that you could have avoided is not very productive and that motivated me to look into possible alternatives.
- kevin_thibedeau 5y ago99% of the time a stack trace shows the culprit for a segfault straight away. No different than debugging Python.
- zanellia 5y agoif we are arguing that implementing a numerical algorithm in C is as easy as implementing it in Python - I would disagree. But maybe I am just wrong :)
- kevin_thibedeau 5y agoThe issue is debugging crashes, not productivity.
- klyrs 5y agoFWIW, I almost always use valgrind before a debugger, when tracking down segfaults. It doesn't catch everything, but 90% of the time, it gets me to the right region of code in a single run.
- zanellia 5y agosure I use valgrind and gdb too - still hard to argue that a segfault is pleasant to debug though?
- klyrs 5y agoGood good, just wanted to advocate for my favorite tool there. But, in my experience, segfaults are usually the easiest bugs to resolve. Unlike a sign error in my math, they're impossible to miss! That said, tooling to get rid of them entirely is not to be sneezed at :)