錠前

世の中には不思議なことをする人間がいる。

よく、扉の鍵を閉めた後に、ノブを回して扉を前後に動かしてみるという行為をする人がいるが、あれは一体何を目的とした行動なのだろうか？

当然の事ながら、鍵を閉めた後なのだから、扉には鍵がかかっている。その扉を無理に開けようとしても、当たり前だが扉が開くことはない。そんな当たり前なことを確認して、一体何が嬉しいのだろうか？

どうやら、本人としては「鍵を閉め忘れていないかどうか」を確認したいがための行動であるらしい。しかし、鍵を閉めた後に扉を開けてみるという行動では、決してその目的が達せられることはないはずである。

なぜならば、鍵を閉め忘れた時には、扉を無理に開けるという確認もし忘れるはずだからである。

すなわち、扉を無理に開けるという行動によって確認できるのは、錠前が期待通りに正しく動作しているか否かという事だけであり、自分が鍵をかけ忘れたか否かという意味では、全く何の確認にもなっていないのである。

それなのに、その行動を執拗に繰り返す人間がいるのが不思議でならない。俺の隣近所に住んでいる奴が、特に著しい。朝、鍵を閉めた後にガチャガチャと数分間に渡って扉をこじ開けようとし続けている。それもかなりの勢いでやるから、音が周囲に響いて著しく不快である。

錠前の動作を疑い、その確認をするのは本人の考え方の問題であり、ましてや、それを何回行おうが他人の知ったことではないはずである。しかし、それは他人に迷惑をかけていない場合の話であり、その行動により少なくとも一人以上、不快に感じている人間がいるのだから、控えるべきだと思う。特に、その行動に余りにも合理性が無い場合には、周囲の人間をいらだたせるばかりだから、なおさらである。

別に、錠前の動作確認をするなとはいわない。だが、せめて静かにやってくれ。うるさいから。

ログ

「主筆」の文字列処理を変更する作業で、プログラムの全体に渡って手を加えた。そのため、今度はデバッグが大変なことになっている。

全く動かないというわけではないのだが、やはり、変更したからには動作を確認する必要がある。しかし、変更箇所が多く全てを確認するのは大変だ。

まぁ、業務用のアプリケーションなら一も二もなくテスト漬けにして品質を担保するのだろうが、所詮ロハで公開しているフリーソフトである。そこまでする気力はない。とは言っても、とは言っても、やはり品質は気になる。

そういうことで、横着しつつも品質を向上できるような方法をいくつか取り入れることにした。

ひとつはassertを大量に埋め込むことである。今までも使ってこなかったわけではないのだが、それでも使用方法は限定的だった。だがこれからは、もっと積極的に導入することにした。

次に、ログ出力機能の追加である。ログを出力させることで、内部の処理が正しく行われていることを確認しようと言う訳だ。ログを出したからとて、直接的に品質向上につながるわけではない。しかし、それでも内部の状態を確認することにより、プログラムの正しさが（一面的ではあるが）確認できるので、まぁ、ある程度の効果はあろうというものだ。

だが、ログ出力機能を付けると言うことは、またしてもプログラム中の至る所に手を加えると言うことになる訳で、逆に状況が悪くなるのではないかという気がしなくもない。

だがまぁ、いいか。

文字列処理の変更

このところ、自分で使うためのソフトいくつか作っていたのだが、そろそろ「主筆」の開発に戻ることにした。

かなり前にもここに書いた覚えがあるが、今現在取り組んでいるのは、「主筆」内部で取り扱う文字列をワイドバイト文字列で統一する作業である。

「主筆」内部では、基本的には文字列はワイドバイト文字列（すなわちwchar_tの配列ないしstd::wstring）で取り扱うようにしているのだが、一部そうでない部分がある。正確に言えば、ファイル名は全てマルチバイト文字列（すなわちcharの配列ないしstd::string）で取り扱っている。

だが、移植性や互換性といったプログラムの品質といったものを考えた場合、文字列は全てワイドバイト文字列で取り扱うのが正しいように思われる。しかし、Solarisはシステムコールやライブラリ関数がワイドバイト文字列に対応していないことが多く、酷く厄介である。

Windowsの場合、ほとんど全ての関数に対して、マルチバイト文字列（実装上はShift-JIS）を取り扱うバージョンと、ワイドバイト文字列（実装上はUCS-2、すなわちサロゲートペアの無い16ビットのUnicode）をおり扱うバージョンとか用意されており、かつ、それらをコンパイル時に切り替えられるようにするたの関数とか用意されている。

つまり、Windows上でプログラムを作る場合は、文字列は全てCStringないしTCHAR型配列として実装すればよく、ライブラリの非互換性などの問題は時々気にしてやればいいだけである。しかしSolarisの場合、外部の関数を呼ぶ場合にはほとんど全ての場合において、文字列のエンコードをマルチバイト文字列に変換してやらなければならない。

例えば、ファイルを開くためにfopen関数を呼ぶにしても、ワイドバイト文字列のバージョンは用意されていないため、ファイル名をマルチバイト文字列に変換してからファイルを開くということをしてやらなければならない。

面倒なことこの上ない。しかも、処理が遅くなりそうで気に入らない。だから「主筆」では、ファイル名などの一部のデータはマルチバイト文字列のままで処理するようにしていた。しかし最近になって、ワイドバイト文字列とマルチバイト文字列の混在による複雑さが手に負えなくなってきたから、面倒さはあるとはいえ全てワイドバイト文字列で統一することにしたのだ。

プログラム内部の処理方式を変えたからといって、基本的には外部に影響を及ぼすことはない。元より、ユーザがマウスとキーボードで操作するだけのソフトである。文字列の形式など問題とはなり得ない。しかし、今回の対応を行うことにより、一部分どうしても影響を受けざるを得ないものがある。

それはプラグイン関数のインタフェースである。プラグイン関数では引数にファイル名を受け取るものがあるが、そのファイル名がマルチバイト文字列（すなわちconst char*）になっているのである。

互換性のためにはconst char*の引数を受け取る関数を変更するわけにはいかないが、逆に手つかずのままにしておくこともできない。だとすると、const wchar_t*を受け取るバージョンの関数を新たに作って提供しなければならないことになる。

どうにも面倒だが、まぁ、仕方あるまい。