gdb in gud

超どうでもいいはなし。

ネットとか見てると、「いまどきgdbなんて…」「それでもデバッガだけはVC++のがいい」とか、そういうふうな話を結構見かけると思うのだけど、それってどうなんだろうか。
僕は、会社でVC++使う機会があったので、デバッガもちょろっと使ったんだけど、どうも、emacsのgudのほうが使いやすいと感じてしまったのだ。いや、だからどうしたって話なんだが、emacsの話は書いてて楽しいので、個人の趣味。

まず、ひとつめ、えーと、「ひとつめ」、というかこれが全てなんだけど、emacsのgudでデバッグしてると、エディタ←→デバッガの移動が超スムーズだ、ということだ。そして、ここで「エディタ」とは、emacsのことだ。つまりエディタへの移動が超スムーズであるということは、コンパイラの実行環境やら、シェルやら、そういうものへの移動も超スムーズだ、ということだ。

VCのデバッガがどうなのか知らんが、デバッガなんて機能はどうでもいいと思うのだ。実際のところ、SEGVしたときのバックトレースがとれて、変数が見れて、ブレークポイント入れれて、ステップ実行さえできれば95%くらいはなんとかなるだろうと思う。ウォッチポイントみたいなものなんて、めったに使わんだろう。データ見るときはprintfデバッグのほうが良いことが多いだろうし。いや、まあ、このへんはデバッグスタイルによるかもしれんが。
重要なのは、どれだけ早くブレークのON/OFFができるか、どれだけ早くバックトレース拾えるか、なのだ。こういう観点で見ると、emacsのgudはデバッガとして大きく劣る、というようなことはないだろう。確かに全体の機能としてはかなり足りないかもしれないが、バックトレース、ブレークポイントという一番重要な部分だけは十分使えるだけの機能になっているので、問題は無いはずだ。（さらに言えば、gdbのコマンドが使えるんだから、実際に機能が足りないということは無いんだけど、gdbのコマンドは僕もあんまり知らない…）

でー、そういうふうに、機能としては十分である、と、なってくると、さきほどのエディタ←→デバッガの移動が超スムーズだ、というのが、他のデバッガに対して大きなアドバンテージになってくるのである。多分。これは、あんまりうまく文章で説明できないんだけど、とにかく、なんか、もう、良い。
eshellで実行→segfault→デバッガ起動実行→バックトレース→発見→修正→コンパイル→eshellで確認、というのが、一切ストレスを感じさせることなく流れるように実行できるのだ。これを感じられるデバッガはemacs+gudをおいて他には無いと思う。
他のデバッガだと、エディタとデバッガ、コンパイル実行環境の切り換えくらいはできるかもしれんが、その中に、shell実行やら、デバッガの出力のコピペやらを混ぜるなんてことはできないだろう。
特に重要なのが、shellの実行が速い、ということだ。デバッガで実行させてるとブレークポイントで止まったりして、いちいち中断させられるのが非常にウザい、けど、パパっとブレークポイント消してしまうわけにもいかん、というような状況はしばしばあるだろう。しかし、shellへの切りかえがスムーズだと、デバッガを放置して、shellで動作確認、というのが可能になる。何度もいうが、それは、一切ストレス無く、スムーズに、である。参考までに、この切りかえは慣れれば1秒弱ぐらいになるかと思う。

まあ、とにかく、よくわからんが、えーと、よくわからん。ここで、「VCのデバッガは慣れてなくても使えるから…」なんて言ったら怒る！！いや、怒らんけど。