連載 プロフェッショナルVB.NETプログラミング 第7回 ファイル入出力（前編） （株）ピーデー 川俣 晶 2002/05/30

---

VB専用ファイル入出力関数とファイル・システム・オブジェクト

　VB.NETの時代には、VB専用ファイル入出力関数(FileOpen関数など)と、ファイル・システム・オブジェクト、どちらを使うのが好ましいだろうか？ もし、過去のソースの互換などを意識せず、まったく新規にソースを記述できるとしたら、どちらを選ぶべきだろうか？

　まず、VB専用ファイル入出力関数は、過去のVB 6からの移行を容易にするように、書式は違っても似通った機能が提供されていることが特徴といえる。例えば、開いたファイルを区別するために整数のファイル番号を使うことは、明らかに伝統的なBASICとの互換性を重視していることをうかがわせる。一方、この方法は使い勝手が良いとはいえない。まったく無関係の整数をファイル番号として使ってしまっても、構文エラーにはならず、実行して初めてエラー・メッセージを見ることになる。あるいは、ほかの開いているファイル番号と偶然重なると、エラー・メッセージも出ないまま、不正な結果を目にする羽目になる。そのような特徴から考えれば、これらは過去の資産を活かすために使われるべきもので、ゼロから新規に開発するプログラム向きとはいい難い。

　では、ファイル・システム・オブジェクトはどうか。こちらの方は、開いたファイルを番号ではなくオブジェクトとして扱うので、関係ない整数を誤って代入して混乱するような事態は未然に防ぐことができる。例えば整数には入出力メソッドはないので、間違った整数を入れてしまっても、間違いなくエラーになる。しかし、COMオブジェクトの世界は、.NET Frameworkの世界の外側に存在するものであり、VB.NETで開発したプログラムを実行できる環境のすべてがファイル・システム・オブジェクトをサポートしているという保証はない。今のところ、Windowsには標準でファイル・システム・オブジェクトが含まれているが、.NET FrameworkがWin32 APIの後継に位置づけられている以上、Windowsではない環境で動作する可能性も無いとはいえないのである。

　また、効率の点からもCOMオブジェクトへのアクセスは好ましいものではない。CreateObjectを使って実行時に参照を処理する方法は効率が悪いし、かといって、参照を使ってラッパー・クラス経由でアクセスするのも非効率である。

　これらのことから考えれば、VB専用ファイル入出力関数も、ファイル・システム・オブジェクトも、どちらを選んでも一長一短ということになる。

　では、どう対処すれば、より良い解決方法といえるのか。それは、.NET Frameworkのクラス・ライブラリの活用である。VB 6のプログラマーなら、Win32 APIを呼び出して活用した人も多いと思うが、.NET Frameworkのクラス・ライブラリを呼び出すということは、それと似た行為であるといえる。しかし、VB 6からWin32 APIを呼び出す場合には特別なDeclare宣言をいちいち記述しなければならなかったが、VB.NETから.NET Frameworkのクラス・ライブラリを呼び出す場合は、そのような宣言は必要ない。では、どのように使えばよいのか。

　次回に続く。

INDEX
	連載 プロフェッショナルVB.NETプログラミング
	第7回 ファイル入出力（前編）
	1．ステートメントを用いたテキスト・ファイルの入出力
	2．ファイル・システム・オブジェクトを用いたテキスト・ファイルの入出力
	3．VB専用ファイル入出力関数とファイル・システム・オブジェクト

　

「プロフェッショナルVB.NETプログラミング」

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）