OuDiary - OuDiaプログラム開発日誌

Visual Studio 2008 の VisualC++ で、画面に表示した文字列が文字化けするという問題に出くわしました。

原因を調べてみたところ、_mbclen() という関数が誤動作していることが分かりました。

_mbclen() 関数は、文字が１バイト文字か２バイト文字かを判定する関数です。
補足しますと、『１バイト文字』とは、１バイトで表すことのできる文字です。半角英数字・半角カタカナがこれに含まれます。これに対して、2バイト文字とは、１文字を表すのに2バイトを必要とする文字のことです。漢字はすべて2バイトに含まれます。

この_mbclen()関数が、"武"という文字を1バイト文字と判定していました。これが原因で、プログラムが文字の境界を誤判定して、文字が化けていました。

さらにいろいろ試してみると、どうもプロジェクトのプロパティで

　プログラム全体の最適化:リンク時のコード生成を有効にする

という項目を選択していると、誤動作することが分かりました。

「最適化を有効にするとプログラムが誤動作する」というのはおそらく、プログラムの側に問題があると思われますが、今のところ原因がはっきりしません。僕ももう少し調べてみるつもりですが、どなたか、同じような経験をなさった方はいらっしゃいませんか？

最近、JScriptを使い始めました。(※ JScript .NET ではなく、WSH上の JScriptです)

といっても、WEB アプリケーションの開発を始めたわけではなく、パソコン上でのちょっとしたテキスト加工の助けになれば・・・というつもりで、もっぱらコマンドプロンプト上で試用しています。たとえば、

1. WEBブラウザでページを開き、 [編集]-[すべて選択]・[編集]-[コピー]で、内容をクリップボードにコピー
2. クリップボードから取得したテキストをJScript で加工し、クリップボードに戻す
3. それを、テキストエディタやExcelなどのアプリケーションに貼り付ける

というようなことができれば便利かな・・・と思ったわけです。

しかしながら、いつも使っているC++と比べると全然勝手が違うので、難渋しています。特に

変数のタイプミスをしても、コンパイルエラーにならずに、プログラムが実行できてしまう(当然、誤動作する)

という特性にはずいぶん悩まされました。「動かしてみて間違った動作に気づくまで、タイプミスに気づかない」というのはあまり生産性がよくないですね。同じ用途のVBScriptには「宣言されていない変数を使うとエラーになる」という動作モードがあるようですが、JScriptには同様のものはないのでしょうか？
「だったらVBScriptを使えば？」とも考えましたが、どうしても、いつも使っているC++に近い文法のJScriptの方が書きやすそうに思えてしまいます。このため、VBScriptは敬遠してしまいます。「ソフト開発者たるものが、この程度の柔軟性がなくてどうするか」とも思うんですけどね。

実は、ちょっと昔に、同じ用途を目指して Perl(Active Perl)を試用したこともありました。それなりに使えそうではあったんですが、

• (1)GUI上でステップ実行のできるデバッガが見当たらない
• (2)ActivePerl のインストールは面倒なので、他人(プログラミングとは無縁な普通の人)にスクリプトを配布するのには向かない

といったところが不便に感じられました。JScriptは、WindowsXP以降には標準装備されているうえ、Visual Studio でデバッグができる点がありがたいです。

JScript・WSHで一番困るのは、入門者向けのドキュメントが乏しいことです。このため、分からないことにぶつかった時には問題解決に時間がかかっています。これでは、スクリプト言語の特性といわれる「習得が容易で、すばやく作れる」というメリットも台無しです。

実際のところ、JScript・WSHを使っている人は、プログラマの集まる開発現場でもほとんど見られません。利点も少なくないプログラミング環境なのですが、入門者向けのドキュメントが乏しく、周囲に聞ける人もいない現状では、「利点の有無を理解できる程度に使ってみよう」という気が起こりにくいのは当然でしょう。

　OuDia Ver0.05.03 を公開してから3日が経過しました。

　OuDia Ver0.05.03 では開発環境を Visual Studio 6.0 から 2008 に置き換えました。ユーザーの皆様のPCにうまくインストールできるのか心配しながらのリリースでした。しかし、それから3日間、ダウンロード数は170ですが、インストールに関する苦情は今のところゼロです。うまくインストールできているみたいですね。

　・・・と、いう解釈の結果、僕は安心してPCから Visual Studio 6.0 をアンインストールしたのでした。

　実は、僕のPCはハードディスク容量が不足しつつあります。Visual Studio 2008 をインストールしたことにより、ディスク容量の逼迫はさらに深刻になりました。このため、一刻も早く古い Visual Studio 6.0 を削除してディスク容量に余裕を持たせたいと思っていました。でも、もし OuDia Ver 0.05.03 でのインストールの障害連絡が来た場合は、原因究明のために Visual Studio 6.0 が必要になってしまいます。

　そんなことを考えながら、僕は Visual Studio 6.0 の削除のタイミングをずっと見計らっていました。 今回、インストールに関する障害情報がないことにより、削除の決断ができたのでした。
 

 このたび、自宅ＰＣのソフトウエア統合開発環境（※)を更新しました。

　従来は、Ｖｉｓｕａｌ Ｓｔｕｄｉｏ 6.0 という統合開発環境を使っていました。しかし、Ｖｉｓｕａｌ Ｓｔｕｄｉｏ6.0 は 1998年の発売で、今となっては古臭いものになっていました。これを最新の Ｖｉｓｕａｌ Ｓｔｕｄｉｏ 2008(Standard Edition)に置き換えました。

※統合開発環境：　簡単に言えば、ソフトウエアを作成するためのソフトウエアです。詳細は、こちらを参照。　

　Visual Studio のバージョンアップは、6.0 以降、.NET・.NET 2003・2005・2008 と小まめに行われていました。しかしながら、安サラリーマンの僕には、Microsoft のバージョンアップのたびに万単位(ものによっては十万単位) の支出をするわけにはとてもいかなかったんですね。このため、Visual Studio のバージョンアップをずっとためらってきたんですが、さすがにそれにも限界が来て、このたび一気にバージョンアップを行ったわけです。

　というわけで、早速OuDiaを Visual Studio 2008 でビルドしてみました。すると、古い Visual Studio 6.0 では発見できなかったバグが露見して大汗をかくという始末。10年ぶりのバージョンアップの効果を早々に見せ付けられる羽目になりました。これ以外にも、開発効率を上げるための新機能がいろいろと追加されています(特に、IntelliSence が比較にならないほど賢くなっています)。

　今回リリースした OuDia Ver0.05.03 は、Visual Studio 2008 による最初のOuDiaとなります。

　僕としては、OuDia　Ver.0.05.03がうまくインストールができるかどうかが心配です。Visual Studio 2008 のインストールと同時に、僕のPCにはWindowsの最新モジュールが導入されているようです（Microsoft .NET Framework 3.5 など）。このため、他のPCで同じように動作するか否かの検証が難しくなってしまいました。 特に心配なのは、以下のような動作環境です。

• Windows Update をあまり行っていないPC
• Microsoft Office がインストールされていないPC
• OSがWindowsXP以外のPC（これは「サポート外」という言い逃れはできますが・・・）。

　そのようなわけで、インストールに問題が起こった場合は、ぜひ作者にお知らせください。この場合、以下の情報をお寄せいただければありがたいです。

•  WindowsのOSのバージョン（[スタート]→[コントロールパネル]→[パフォーマンスとメンテナンス]→[システム]で確認できます）
• .NET Framework のバージョン（[スタート]→[コントロールパネル]→[プログラムの追加と削除]で確認できます）
• Windows Installer のバージョン（[スタート]→[コントロールパネル]→[プログラムの追加と削除]で確認できます）

新人プログラマからよく聞かれる発言に、こんなのがあります。

「プログラムを動作させてみたところ、実際に出力されたデータは正しい値の10倍でした。そこで、データを出力直前に10で割るようにしました。これにより、プログラムは正しく動作するようになりました・・・」。

しかし、これで 仕事が終わりになったつもりになっているようなプログラマが作るのは、おろらく理解困難な低品質プログラムです。

データが正しい値の10倍になったのには、それまでの処理の過程に必ず原因があるはずです。もしかしたら、それは設計の根本に関わるような勘違いかもしれませんし、他の処理でも同じような問題を抱えているかもしれません。

その根本原因を放置して「10倍の値が出たから10で割って正しい値が出るようにしました」では、後からそのプログラムを見ても「何でここでは10で割っているのか？」ということが分かりません。こういうつじつま合わせが積み重なったプログラムは、意図不明の処理が満載の、理解困難なものになるわけです。

　こういう対応をするプログラマは、
　　「どうすれば『正しく動くプログラム』になるのか」
というところまでしか見えていないように思われます。いや、もしかしたら
　　「どうすれば上の人に言われたとおりに動くプログラムになるのか」
ということしか考えていないのかもしれません。

でも、『正しく動くプログラム』と『正しく作られたプログラム』はイコールではありません。 冒頭に挙げたプログラムは、『正しく動くプログラム』であったとしても『正しく作られたプログラム』ではないんですね。

『正しく作られたプログラム』を作るプログラマは、「このプログラムはどうあるべきか」という考え方をとります。そういう人は、10倍の値が出た時点で、原因を究明しようとします。たとえ、その時点では動かすことを優先して10で割るという応急処置を施したとしても、それを放置することはせず、いずれ機会があればプログラムの構造を正常化します。

世の中には、「開発を進めていくうちに、いつの間にか設計が破綻していた」というプログラムの話はいくらでもあります。それを避ける必要条件の一つは、

• プログラマ一人ひとりが『正しく作られたプログラム』への意識を失わないこと

ではないかと考えています。