連載

改訂版
プロフェッショナルVB.NETプログラミング

Introduction:Visual Basic .NETへの飛躍

株式会社ピーデー 川俣 晶
2004/01/28
Page1 Page2 Page3

 本記事は、(株)技術評論社が発行する書籍『VB6プログラマーのための入門 Visual Basic .NET 独習講座』の一部分を許可を得て転載したものです。同書籍に関する詳しい情報については、本記事の最後に掲載しています。

 開発環境の比較

 本連載では、主に言語の文法の変化を中心に扱い、開発環境の変化や、ADOからADO.NET、ASPからASP.NETへのステップアップ方法までは踏み込まない。しかし、開発環境の変化については、サンプル・ソースを試すときにも関係してくるので、概要のみ解説しておく。

 VB 6は、Visual Studio 6.0(以下VS 6.0)という大きな製品群の一部を構成する要素である。VB 6だけ単体で購入することもできるが、VB以外の言語処理系もサポートされるVS 6.0のパッケージを購入している人も多いだろう。VS 6.0は、VB/C++/Javaといった開発言語のツールを1つにまとめた製品である。しかし、必ずしも1つの統合された製品というわけではなく、Java言語の処理系であるVisual J++はセットアップが別CD-ROMになっているし、インストール後に利用するときにも、VBとVisual C++とVisual J++は別個の開発ツールとして起動する。これらのツールはそれぞれ微妙に使い勝手が違っていて、VBに慣れているプログラマーがC++の文法だけ勉強しても、すぐにVisual C++を使いこなせるわけではない。

 一方、新しいVisual Studio .NETでは、すべての開発言語が1つの環境に統合されている。1つの統合開発環境の中に、VB/C++/C#が含まれていて、すべて同じエディタやデバッガを使用する。開発に使用する言語は、プロジェクトを新規作成する時点で選択すればよく、ほかのプログラム言語の知識は必要ない。このような構造のため、プログラム言語が変わっても微妙な使い勝手の違いは起こらず、いちいち別のツールとして起動する必要もない。ただし、意図的にプログラム言語を変えると使い勝手が変わるように配慮された部分もあるようで、例えばC#とVB.NETでは、コントロールのイベントの設定方法などが異なっている。とはいえ、相違はそれほど多くはない。複数のプログラム言語を掛け持ちするプログラマーには好ましい進化だが、その代償として、VS 6.0との細かい使い勝手の部分で互換性がなくなっている。一応、キー操作はカスタマイズ可能で、VB 6風の設定も用意されているが、まったく同じになるというわけではない。

 実際のウィンドウのレイアウトもガラッと変わっている。統合環境のウィンドウは、図0-9から図0-10のようにデザインが変更された。

●図0-9 VB 6の統合開発環境
 
●図0-10 VS.NETの統合開発環境

 また、新規プロジェクト作成時の選択肢の違い(図0-11図0-12)を見れば、1つの環境で複数言語を扱うようになったことがよく分かる。

●図0-11 VB 6で作成可能な新規プロジェクトの選択ダイアログ画面
 
●図0-12 VB.NETで作成可能な新規プロジェクトの選択ダイアログ画面

 ウィンドウの構成、メニュー、キー操作などが変更されたとはいえ、Visual Basic的な作業の流れが変わるわけではない。例えば、Windowsアプリケーションを作成するために、コントロールを選んでフォームに貼り付け、イベントの中身のコードを書き加えてプログラムを完成させるという定番の流れが変わるわけではない。ヘルプを参照しつつ、1つ1つの操作を行うメニューやキーなどの相違を確認しながら作業を進めれば、決して戸惑うものではないだろう。そういう意味で、操作面での相違は、ただ単にどれを使えばよいかを把握するだけの作業であり、ちょっと使い込めばすぐに慣れるはずだ。その程度のことは、VB 6からVB.NETへの移行の中では実にささいな問題でしかないのである。本当に大変なのは言語仕様の変化と、新しいクラス・ライブラリ、そして、本格的なオブジェクト指向の導入にある。

 言語仕様の変化

 VB 6とVB.NETの言語仕様、つまりプログラムの書き方の文法には共通点も多いが、相違点も多い。まずは“論よりソース”ということで、小さなプログラムを比較してみよう。

 まず、こんな小さなプログラムをVB 6で書いてみた。新しいプロジェクトの作成で標準 EXEのプロジェクトを作成した状態で、下記のとおりにコードウィンドウに書き込んだ。

1: Private Sub Form_Load()
2:   a = 1
3:   b = "2"
4:   Debug.Print a + b
5: End Sub
リスト0-13 VB 6で記述した小さなサンプル・プログラム

 これは変数宣言も行わず、無造作に整数と数字の文字列を加算して、それを[イミディエイト]ウィンドウに出力させている。このように変数を宣言しなくても、またデータ型の違いを意識しなくても、適当にソースを書くだけで何となく結果が得られるのがこれまでのVisual Basicらしさといえるだろう。これを実行すると、期待どおり“3”という数字が出力される。

 では、これと同等のソース・コードをVB.NETで作成してみよう。Visual Studio .NET(以下VS.NET)の[Windowsアプリケーション]のテンプレートでプロジェクトを新規作成し、フォームをダブルクリックすると[コード]ウィンドウが表示される。そこで以下のようにソースを書き込んで[F5]キーを押せば実行できる。

1: Private Sub Form1_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load
2:   Dim a, b
3:   a = 1
4:   b = "2"
5:   Trace.WriteLine(a + b)
6: End Sub
リスト0-14 リスト0-13をVB.NETで書き換えたプログラム

 結果は同じく“3”となるが、いくつかの相違がソース上に現れていることが分かるだろう。まず、“Private Sub 〜”の宣言行の相違はここでは無視することにしよう。これはIDEが自動生成してくれたものなので、自分で書く必要がないからだ。次に気付くのは、VB 6のソースにはなかったDimステートメントだろう。VS.NETで作成したプロジェクトは、生成時のデフォルト設定で「Option Explicit機能」がオンとなっており、ソース・コード上にOption Explicitの文字が見えなくても、それが記述された場合と同等の効力を発揮する。つまり、デフォルト状態のVB.NETでは、宣言されていない変数は使用できず、必ずDimステートメントで使用する変数を宣言しなければならないのである。なお、この設定はプロジェクトのプロパティから変更することができる。しかし、通常はこの設定は変更せず、必ず変数宣言を行うように習慣付けた方がよいだろう。変数のスペルミスはソースを見ても気付きにくく、無駄な時間を使いがちである。これに対し、宣言を習慣付ければ、変数のスペルミスをコンパイラが発見してくれる確率が高くなり、バグの早期発見に役立つはずだ。なお、Option Explicitの詳細は、「Chapter 13:Option Explicit」で解説する。

 次は、最後の“Debug.Print”が“Trace.WriteLine”に変わっている点が目に付くだろう。Debug.PrintはVB 6の言語仕様の一部を構成する機能で、Visual Basicだけが使うものである。一方、Trace.WriteLineは、.NET Frameworkのクラス・ライブラリの一部として提供されるもので、.NET Framework上のすべてのプログラム言語から利用可能な機能である(クラス・ライブラリについては、このあとの.NET Frameworkより得るもので詳しく述べる)。つまり、共通のライブラリに機能が提供されたため、VB 6だけで利用可能な機能の出番はなくなり、退場したということである。変わってしまったものは仕方ないので、素直に名前を書き換える必要がある。

 さて、もう1つこの行で目に付くのは、括弧の有無だろう。VB 6ではDebug.Printの引数を括弧でくくる必要はなかったが、VB.NETのTrace.WriteLineでは括弧でくくらなければならない。VB 6では、Functionキーワードで宣言された関数を呼び出す際に引数を括弧でくくる必要があったが、Subキーワードなどで宣言された手続きを呼び出す際には括弧は不要だった。しかし、VB.NETでは、どちらの場合でも括弧が必要になった。これも、素直にそういうものだと思い、ひたすら括弧を付けるように習慣付ければよいだろう。

 細かく見ていくと、かなりの大変更と思うかもしれないが、変わっていない点もある。例えば、整数と、整数を表現した文字列を型の違いも考えずに無造作に足し算して、きちんと計算結果の「3」が得られているというのは、C++やC#といった、ほかの言語とは異なるVisual Basicらしい挙動なのである。そのようなVisual Basicらしい特徴は、VB.NETにも継承されている。もし、このような挙動が好ましくないと思うなら、もっとデータ型を厳格に扱う、Option Strictという機能も用意されている。

 実行環境の変化

 コンピュータのプログラム言語は、おもにインタプリタコンパイラに分けられる。インタプリタは実行時にプログラムを解釈するが、コンパイラはコンパイルという処理でプログラムを解釈して、マイクロプロセッサが直接実行可能な機械語コードを生成する。コンパイラを使用すると、コンパイルという手順が増えるが、その代わりに、実行時の速度が速くなる。一方、インタプリタはコンパイルという手続きを経なくてもすぐに実行できて小回りが利くので、手軽に使うのに適している。そのため、初期のBASICは、インタプリタとして実装されることが多かったが、実用ソフトの作成に使われるようになると、コンパイラとして実装されたBASICも増えてきた。VB 6もコンパイラとしての機能を備えており、高速で実行できる機械語コードを生成することができる。

 だが、機械語コードを生成することは、最終的なゴールではない。なぜなら、機械語コードにも弱点があるからだ。機械語とはマイクロプロセッサの構造に依存するものであるため、互換性のないマイクロプロセッサ上では実行できないか、あるいはエミュレーションで実行するしかなくなる。一般的にいえば、エミュレーションを行うと、実行速度はかえって遅くなる恐れがある。また、マイクロプロセッサに直接かかわるものであるため、セキュリティの懸念も出てくる。インターネット上には必ずしも出所が定かではないプログラムが多数存在するが、その中には便利で利用価値の高いものも少なくない。しかし、そういうプログラムを生の機械語として実行したとき、万一悪意ある機能が隠されていると、監視や防衛手段がほとんどないままに、プログラム・コードが実行される恐れがある。生の機械語プログラムをそのまま配布して実行するシステムはあまりに危険である。

 このような問題を解決する方法として考えられているのが、仮想マシン(Virtual Machine)という方法である。仮想マシンは一種の空想上のマイクロプロセッサで、仮想的な固有の機械語を持っている。プログラム言語のコンパイラは、生の機械語ではなく、仮想の機械語を生成する。そして、仮想の機械語は、仮想マシンによって解釈され実行される。

 仮想マシンが仮想の機械語を解釈する方法は2種類ある。1つはインタプリタで、もう1つはコンパイラである。現在は、プログラムのインストール時や実行時にコードをコンパイルしてから実行するという方法が主流である。もちろん、このコンパイラは生の機械語を生成するが、コンパイルする段階で厳密なセキュリティ・チェックが入るため、生の機械語プログラムを配布するよりもはるかに安全性が高い。また、仮想マシンを交換すれば、マイクロプロセッサのアーキテクチャの違いに対応することも容易である。このようなコンパイラを、JIT(Just In Time)コンパイラという。VB.NETでは、インストール時や実行の直前などにこのようなコンパイルが行われる。

 仮想マシンとしては、Java用のJavaVMが有名である。Microsoftは新しい世代の実行環境として、.NET Frameworkを開発したが、この中にも仮想マシンが含まれている。VB.NETは、文字通り、この.NET Frameworkの仮想マシンで実行するプログラムを開発するために使用されるプログラム言語である。そのため、PentiumシリーズなどのIntel x86(IA32)アーキテクチャ向けの開発言語であるVB 6とは、まったく異質の存在になっている。

 VB.NETで開発したプログラムを配布する場合は、作成したプログラムだけでなく、.NET Frameworkランタイムもいっしょに配布する必要がある。これは、一見VB 6で開発したプログラムを配布するときにランタイムDLLをいっしょに配布する必要があることと同じように見えるかもしれない。しかし、VB 6のDLLはあくまでVB 6専用のDLLであるのに対して、.NET Frameworkランタイムはほかのプログラム言語と共通のものである。この手間は、過渡期に必要とされているもので、Service PackやWindows Updateを利用してインストールすることもできる。新しい世代のWindows OSには順次標準で組み込まれる予定であり、将来的にはランタイムの配布は不要になるだろう(Windows Server 2003には標準で含まれている)。

 なお余談だが、Windows XPにはVB 6のランタイムDLLが標準で含まれているようで、ランタイムDLLを明示的に追加しなくても、VB 6で作成したアプリケーション・ソフトが動作した。このような便利さは、これまではVBでのみ享受できたものだが、.NET Frameworkの時代になれば、VB以外の言語でも同じランタイムで動作するため、便利さを享受できる範囲が拡大するといえる。


 INDEX
  [連載] 改訂版 プロフェッショナルVB.NETプログラミング
  Introduction:Visual Basic .NETへの飛躍
    1.大きな変化を伴うバージョンアップ
  2.開発環境の比較、言語仕様の変化、実行環境の変化
    3..NET Frameworkより得るもの
 
「改訂版 プロフェッショナルVB.NETプログラミング 」


Insider.NET フォーラム 新着記事
  • 第2回 簡潔なコーディングのために (2017/7/26)
     ラムダ式で記述できるメンバの増加、throw式、out変数、タプルなど、C# 7には以前よりもコードを簡潔に記述できるような機能が導入されている
  • 第1回 Visual Studio Codeデバッグの基礎知識 (2017/7/21)
     Node.jsプログラムをデバッグしながら、Visual Studio Codeに統合されているデバッグ機能の基本の「キ」をマスターしよう
  • 第1回 明瞭なコーディングのために (2017/7/19)
     C# 7で追加された新機能の中から、「数値リテラル構文の改善」と「ローカル関数」を紹介する。これらは分かりやすいコードを記述するのに使える
  • Presentation Translator (2017/7/18)
     Presentation TranslatorはPowerPoint用のアドイン。プレゼンテーション時の字幕の付加や、多言語での質疑応答、スライドの翻訳を行える
@ITメールマガジン 新着情報やスタッフのコラムがメールで届きます(無料)
- PR -

注目のテーマ

業務アプリInsider 記事ランキング

本日 月間
ソリューションFLASH