Entry

プログラミングメモ - デバッグのコツとか少し

2009年03月30日

こちらの話から。あまり書くこともないんですけど,ちとだけコツとか。

デバッグやテストをするときには、ソースコードを変更してはいけない。デバッグをするためにprint文を埋めこむなどというのは以てのほかである。(1)ビルドのコストがかかる。(2)デバッグ版と正式版という複数のものを管理するコストがかかる。問題をいたづらに複雑化している。(3)デバッガなどの機械力を使うのが正しい姿である。

2009-03-22 - 未来のいつか/hyoshiokの日記

printf(3) でデバッグすると,元のソースが汚れてしまったり,版管理が大変になってしまうというのはたしかにあるんだろうな,と思います。あたしも以前,デバッグプリントをリリースビルドに書いたままにしちゃったことがあって,大目玉を食らったことがある。こゆことをしないために,デバッグモードのビルドオプションで,マクロを切り替える仕組みがあったりするんですけどね(MFC で言うなら TRACE や ATLTRACE2 を使いましょう,とか)。そゆのを知らないで,じかに printf(3) を使うっつのは,かつてのあたしのような,ある意味問題外の所業なわけで,まぁ,なんつかゴニョゴニョ……。で,おそらくこゆのは MFC で用意するまでもなく,大抵のソフトベンダでは,そういった仕組みを自前で用意しているんじゃないかとも思います。もちろん,あたしんとこにもある。

一方で,デバッグ環境を構築する一般的な方法ってのは,なかなか定立しづらかったりするのもたしかだったりするわけで,printf(3) でデバッグするのが一概にダメかというと,そうでもない気がしています。この頃は C++ を使ってるので,デバッグターゲットのクラスを継承したデバッグ用のクラスを作ってデバッグ(兼ユニットテスト)してるんですけど,これなら,ビルドのコストはかかるかもしれないけれど,ターゲットのソースはいぢらなくて済むし,デバッグ用ソースの版管理も比較的楽。もちろん,printf(3) を使ったメソッドでフックすることもできます。

あと,デバッグ環境云々の前に,まずデバッグしやすく実装するっつのも,あったりするんでねいかと思っていたりします。複数の処理をひとつの関数(メソッド)にまとめて書いちゃったりすると,テストでとても苦労します。手馴れた人ほど,デバッグ時にも楽に環境を構築できるような書き方をしている。これも一般論でどうこう言える話じゃないんですが。

逆に,デバッガ向けのビルドバイナリを信用しすぎるというのもアレで,例えば,MFC のデバッグモードなんかだと,動的にメモリを取ってくる(new する)と,バッファ・オーバーラン検出用にメモリがきれいになってしまったりします(特定の値で埋められる)。ここでメモリ初期化忘れのバグがあったりすると,デバッグモードだときれいに動くのに,リリースモードにすると動きが変わる,なんてこともあったりする。んなもんで,それぞれのデバッグ環境の性質をしっかり踏まえておくってのも重要なんでねいかな,と。

並び立てて書いちゃって,オチついてないけれども,ま,そんな感じ。

Trackback
Trackback URL:
Ads
About
Search This Site
Ads
Categories
Recent Entries
Log Archive
Syndicate This Site
Info.
クリエイティブ・コモンズ・ライセンス
Movable Type 3.36
Valid XHTML 1.1!
Valid CSS!
ブログタイムズ

© 2003-2012 AIAN