そして私は失われた方法を使い、この場所に辿りついた

おはようございます。
本日の当番、プログラマのM.L.Kです。（LはLogのLです。Log&Exp!）

というわけで、デバッグ用出力の話です。

プログラミング経験がある方々は、ご存知だと思いますが、大抵の開発環境には、デバッグ用の出力命令として、TRACE命令（もしくは、それに準ずる関数）という、デバッグ用の画面に任意の文字列を出力する機能が用意されています。

このTRACE命令、処理の内部状態を把握する際に、手軽に使用されるのですが、致命的な弱点が２つあります。
ひとつは、外部デバイスに出力するため、一定以上の速度がでないこと。もうひとつは、出力の履歴を残せる範囲（スクロール可能範囲）に限りがある、ということです。

例えば、１秒間に６０回の更新が行われる処理上で、１００個あるキャラクタ全ての３次元座標の変遷を確認したい、となった場合、これをTRACE命令で実装すると、大変なことになります。

まず、外部出力の割り込みのために、１秒間に６０回の更新が行われなくなります。下手すると、１秒間に２回程しか更新されない、ということになってしまいます。

通信用のデバイスや、メディアデバイスと同期をとる必要があったりすると、致命的な問題も発生します。
なにより、こういった確認が必要なとき、バグ原因の究明を目的としていることが殆どなので、プログラマはもう既にイライラしています。
そんな状況で、通常の１／３０の速さで動作などという事態を余儀なくされるなら、確実にキレます。職場内の雰囲気が悪くなります。ダメダメです。

また、出力内容を確認し易くするために、文字列内に目印を入れたり、改行をふんだんに使用していたりする（通常はこういう工夫をします）と、「あっ」というまにスクロール範囲外に流されていってしまうので、極力改行を減らす必要が出てきます。

当然、内容は見辛くなります。

こういった確認が必要なとき、何時間もソースコードとにらめっこした後だったりすることが殆どなので、プログラマはもう既に目がお疲れです。
そんな状況で、通常の３０倍も見辛い文字列を確認するなどという事態を余儀なくされるなら、確実にキレます。職場内の雰囲気が悪くなります。もうダメダメです。

こういった危機的状況を未然に回避するために、デバッグ用のメモリ領域に文字列を出力する、という、やや古典的な技を使用します。

　　　デバッグ用のメモリ領域に出力
　　　　　　　　　↓
　　　適当なタイミングで処理を中断
　　　　　　　　　↓
　記録の先頭位置からメモリダンプを表示
　　　　　　　　　↓
　　　　　　任意の範囲をコピー
　　　　　　　　　↓
　　　バイナリエディタなどにペースト
　　　　　　　　　↓
　　　　　　　ファイル保存
　　　　　　　　　↓
　　　　　拡張子を‘txt’に変更

これをダブルクリックすると、座標記録テキストの出来上がりです。

古典的とはいえ、メモリダンプ上の文字列を直接読んでいた昔に比べて、かなり楽にはなっています。偉大なりコピー＆ペースト。

もっとも、この方法も、確保できるメモリの容量に限りがありますので、文字列での出力にしてしまうと、確認するのに十分ではないかもしれません。

そうした場合、結局、生のバイナリを出力して確認することになってしまうのですが、こういった確認が必要なとき、プログラマはもう既に混乱気味なので、生バイナリを読むよりも前に、取り敢えずキレます。
職場内の雰囲気も悪くなりそうですが、案外そんなこともありません。

こういった確認が必要なとき、他の皆んなはもう既にきちんと仕事を終えて、家に帰っているからです。