idea-native2-debugger VS pdv

CLion uses lldb.

I wrote https://github.com/daym/idea-native2-debugger as a stop-gap. It uses gdb and works in IntelliJ IDEA Community edition. Setting it up the first time is kinda weird since you need to add a new run/debug configuration "Native2Debugger". I could not figure out how to hook this directly into the existing run configuration that you use to run your program to begin with. Otherwise, I like how it turned out.

If you want a standalone frontend, https://github.com/epasveer/seer is extremely good.

And emacs has gdb integration. By now I tried it, and... I guess it's better than nothing.

>After playing around with a bit of C and trying gdb, I asked myself if this is really what people use. The display constantly breaks and there's not a lot of stuff to quickly walk through code and visualize what it's doing.

As someone doing unix programming since 2001, hell no, that's not what I use (directly), for the reasons you say.

I mean gdb in the backend is okay. But gdb actually specifies Gdb/Mi, a protocol to remote control it.

I use IntelliJ IDEA. I wrote https://github.com/daym/idea-native2-debugger which is a native debugger plugin (that uses gdb in the back) for IntelliJ IDEA Community Edition. You can also use CLion (needs subscription) and that uses lldb in the backend instead of gdb.

Some of my colleagues use emacs (with gdb remote thing). Seems to work OK too.

Earlier in life I used ddd https://www.gnu.org/software/ddd/ a lot--but nowadays I just stay in IDEA.

I could see C++ or Rust maybe adding that eventually, but it seems unlikely for Zig unless they relax some of their core design goals. The problem with invariant assertions is figuring out when exactly they should run, and that idea that something might run _every_ time any public method is called or whatever definitely conflicts with the design they're going for.

That said, Zig does make it pretty easy to handle a lot of the features you might want. As a library, you can offer the ability for a person to rewrite a type (maybe only in non-optimized modes if you want) and check the invariants before/after every public function call. You can always add explicit pre/post-condition checks to any function you'd like. Invariants in your inputs/outputs can be hoisted to the type checker (I wrote a toy project doing this [0]). Like...at some point you have to describe what you want to check and when you want it to run for the invariant checking to be useful, and Zig allows you to write the checks and use comptime magic to place them where you want them to run, all in the userspace of the language. Which language features would you like to make the process smoother (automatic subtype resolution on a lattice of constraints, a bit of syntax, ...)?

[0] https://github.com/hmusgrave/pdv