VB6と.NETの根本的な違い
  (C) 2001 A c t o r .N e t Soft Ware



 以下に公開するソースなどの著作は 篠田直樹 に復帰します。
原則として無許可で使用する事が出来ますが、ここに書かれている内容を
直リンクや引用などであたかも第三者が作成した様に見せたり如何なる事情でも金銭が発生する行為を禁止します。




VB.NetとVB6までの違い、これを理解せずしてVB6で組んできた者が
すんなりと開発環境の移行を果たす事は難しいだろう。
まず、以下に大きな点を挙げていく。

(1).Netはバーチャルコンピュータを装備した上で実行する。
(2)VBの持つ命令はクラス化されている。
(3)マルチスレッドが公式的に標準サポート化された。
(4)Win32 APIが.NET APIへ吸収された。

これらはあくまでも筆者が把握出来ている事項であり、公式的な文章を纏めたものでは無い事を免責しておきたい。

(1)
1つめは今まで、VBをやってきた人にはランタイムの厄介な問題で躓く事が多々あったかもしれない。

・IEのバージョンを上げたりVB自体のランタイムを入れないと動かない、
・VB同士のアプリケーションにランタイムを内包するとランタイム同士の競合が起きる。

こういった問題が.NETコンポーネントに集約される事である一定の厄介な問題は解消出来るようになった。
.NETコンポーネントはOSに依存しない、つまりJAVAの概念そのものである。
つまり.NETランタイムさえあれば各プラットホーム上に.NETバーチャルコンピュータを構築する為に
アプリケーションを実行環境に左右される事はない。
そして当然ながらアセンブラも扱える。
裏を返せば.NET自体は一つの言語として集約される、つまりC#もVC++もVBも裏でコンバートしているだけで
本質的な考え方や書き方が統一されてしまう、しざるを得ない結果になる。
VB.NETになって開発者が激減したのは正にそういった、考え方が根本的に厳格化された点である。
面倒な事を短縮できたVBのメリットが消失した土台で実際の開発を考えた場合、結果的にVB.NETは却下の方向に向くのはやむを得ない。
例えば、Format関数を扱う時にVB6では引数に渡すとき、型を考えずに意図するものが帰っていたが
.NETになってからはきちんと型変換しない限り真面目に意図する事をやってくれない。
つまり、今まで使っていたVB関数に渡す引数に厳格な型指定を要求される様になった。
公式的にもやはり、型宣言や受け渡しの厳格化は当然であるという事の様だ。


(2)
これは(1)に付随したもので、オブジェクト的なバーチャルコンピュータを装備する以上、命令を
クラス化(カプセル化)する必要が出てきたと考えられる。
つまり、明示的に「どこの何」というものを指定してやらなければならないという事だ。
今までLeft関数などを直接書くのが当たり前だったが、.NETからはMicrosoft.VisualBasic.Leftと書いて
初めて扱えるようになる。
もし、これをはしょりたいのならば、Imports [予約名]  Microsoft.VisualBasic の様に書き、
[予約名].Left と書く必要がある。
非常にまどろっこしい様だが、筆者が解釈する限り、Leftやそれらに関する関数は他社コンポーネントを実装する
事で同じ関数にぶちあたる可能性がある。
(他社コンポーネントにLeftやRightなんてものは普通に持っている場合が多い。)
こういった事を解消し、明示的にする事でパフォーマンスの向上を図っている様に思える。
又、今まであった便利な関数も組み合わせて作れるものや仕様上で特に使わなくても済むものは消えている。

言語としては良い方向に進化していると思えるが、実際にはVBプログラマの殆どは
C言語の類や基礎的なコンピュータの仕組みに慣れていない人が多い為に理解が難しくこの壁が越えられない事が多い。
わかってしまえば別に難しい事では無いが、そのわかる課程そのものに基礎が無い場合は壁を超えるのが非常に難しい。

その一つにVBプログラマは変数宣言の概念的な部分をきちんと把握している人が少ない。
つまり何の為にどれだけのメモリを取れば良いという考え方が薄いのだ。
逆にVBはそういったユーザライクな部分で日本では爆発的にVBプログラマが増えた経緯もある。
.NETがこういった部分に制約をかけたのはオブジェクト的な言語として進化する必要があった為である。
例えば、今までのVBでは自動的に型変換を行う機能があった。
これはプロとしてVBをやっている人間にとっては非常に奇怪な事で頭を悩ます結果になる。
ディメンジョン(Dim)を宣言した変数でも計算式を加えると勝手に小さい容量の型に変換を行う性質がある。
こういったお節介が、意図しない結果やバグを生む結果になりかねない、従って計算式を加える時は型指定がされていても
敢えて型変換をしなければまともな結果は出ない。
VB側でもこういった裏でからくりを作るのは難しく、コンパイラーにバグを作りかねない結果となる。
本来、言語としてあるべき姿は明示的に「何をどうする」といったものが無ければならない。
途中をはしょって何も知らない人に「これやって」と言っても理解は出来ないし、
知っている人でも意味解釈を間違える事は十分に考えられる。
そういった意味ではVB6のコンパイラは非常に文法解析能力優れた高度なコンパイラとも言える。
.NETではそういった意味解釈の部分を明示的に書かなければならなくなった。
この部分でVB6プログラマが躓いている様に感じる。
そして、オブジェクトの概念にいきなりVC++の概念を取り入れた点だ。
今までVBにはオブジェクトに対して配列を視覚的に割り当てる事が出来たが、.NETからは
ソース上でしか扱う事が出来ず、しかもそのコントロールをGUIで設定する事ができない。
VB6プログラマは殆どの場合、GUIに頼ってきた筈なのでいきなりこういった概念を持ち込まれると理解に苦しむ筈だ。
恐らく、マイクロソフトの言い分では、フォームに直接コントロールを貼り付ける行為はプログラムの
パフォーマンスを落とすのでやって欲しくない、かつ.NETコンポーネント自体がそういう仕様にしてしまえば
.NETランタイム自体の開発が楽になるという意図があったのだろう。
実際、VB6の様なGUIで画面を作れる言語は他に見当たらない、VBだけの為にそういった拡張はしたくない
というのがマイクロソフトの本音だろう。

只、現実問題としてVB6が抱えた問題の一つにパフォーマンスがある。
複数のOCXをフォームに貼り付けるとメモリーを馬鹿食いし、動作が非常に重くなる。
こういった面でVBで開発すると質が悪いと言われる事も屡々だった筈だ。
又、コントロールを例えば30個貼り付けて配列にした時、一つのプロパティを変更する為に画面上で
一つづつしか変更出来ない項目があったとすると30回、同じ事を繰り返すか、frmファイルをテキストで開いて
部分的にリプレイスを掛けるかどちらかになる。リプレイスできないものはやはり手作業になる。
ソースで書いた場合、初めは時間が掛かるが、後に変更があったとしてもコードを追加するだけなので
割と楽に済む場合が多い。
簡単に言うと、windowsとLinuxを扱う人がいて、どちらの方が作業が楽かという話と似た様なものだ。
視覚的に扱った方が早いか、コマンドを覚えて全てコマンド操作した方が早いかの違いである。

VB6のサポート満了の関係上、.NET 2005 からはVB6ユーザを救済する為に上記の制約が殆ど消えた。
しかし、先祖返りをした言語の意味解釈は複雑でやはりバグを生みやすい。
こういった情報は各掲示板に色々と載っている様で、頭を抱える種にもなっている様だ。
筆者としては、はなるべく.NET 2003 の仕様で作る事を勧める。

只、注意して貰いたいのはあくまでも.NETベースの開発は.NETコンポーネントに頼る必要があるという事だ。
もし、これに依存しない形での開発を希望するならDelphiかCに移行した方が良い。
又、.NET自体は既にセキュリティ的な欠陥が指摘されている。
Windows Vistaを最後に.NET FrameWorkは過去の技術遺産となるだろう。


(3)
これについてはここで語るより本家の内容を見た方が良い。
VB6では基本的にマルチスレッドはサポートされていなかった。
複数の実行を行うにはC言語でCOMコンポーネントを作成し、これをVB側から叩く
事で擬似的にマルチスレッドを可能にする、又は非公開の機能を使う必要がある。
(筆者はVB6での非公開機能については残念ながら把握していない。)
つまり、これが出来るという事はVBでもほぼC言語やJAVAと同等の事が出来る事を意味する。
実際、既にVBは今までのボトルネックとなる仕様が殆ど破棄された為、理論上は
VBでの制御系開発も出来たとしておかしくはない。
(但し、制御開発に関して言えば文献が見当たらない為、出来たとしてもWindows系OSに限られるだろう。
 今までMicrosoftはモバイル、特に携帯OSの開発に力を入れて来た、理由はパソコンOSの需要が飽和してきたからだ。
 布石として投入する上で、VBがデバドラ開発出来る様になれば開発期間やコストは必然的に下がる。
 ハード設計も一貫した仕様になりざるを得ない為、結果的にハード製造のコストも下がる。
 実は携帯の分野でハード構成が一貫せず、頭を悩ませているのは携帯のファームやソフトを作っている会社だ。
 今は無理だったとしても、先々において可能となる可能性は十分に考えられる。)
http://www.microsoft.com/japan/msdn/vs/vb/vbtchasyncprocvb.asp



.NET FrameWorkがもたらす恩恵はランタイムコンポーネントの一元化により、実行環境毎の対応や
ランタイムバージョンの差異を吸収する事にあるが裏を返すとプログラムの実行時に毎回、裏でコンパイルする為、
規模の大きいアプリ程、初回の起動に時間が掛かる事になる。
もう一つは.NET FrameWorkの仕様上、1.XはOSの起動後、アプリを立ち上げる初回にバーチャルマシンの
初期化が行われる事になっているが、この初期化にかなりロスタイム出て遅いというイメージが拭えない。
筆者の実測では初回の起動に7秒を要し、内4秒がバーチャルマシンの初期化に使われている事が分かっている。
この様な問題はOSの仕様変更によって2.0や後継の3.5で吸収されていくと考えられる。


(4)
.NET FrameWorkではWin32 APIは直接コールしない。
勿論、直接コールする事は出来るが余程の事がない限り、必然性そのものが特に無い様に感じる。
今までは直接コールする必要があった為、APIビュアというものが標準で提供されていたが.NETでは配布されない。

http://www.microsoft.com/japan/msdn/net/general/win32map.aspx

この傾向は今後Win32 API自体が.NET FrameWorkに吸収される事を予言している様に感じる。
今後、DirectXも整備が進み、VISTA以降のOSからCOM群が.NET FrameWorkに吸収されていくだろう。
XPまでのOSに搭載されている画面GUIのAPI群は既に古く、次世代の画像処理とかなりのギャップを生じている。
このギャップを埋めるべく、新OSのVISTAでは画面GUIのAPI群を全てDirectXに切り替えている。
恐らく、.NET FrameWork 3.0以降からDirectXが本格的に.NET FrameWorkに吸収されていくものと思われる。
最も、過去DirectXがCOMとして独立してから現在の完成系に至るまで10年程の歳月を要している為、
完全に吸収されるまでに同等の歳月が掛かるかもしれない。

又、こういったDirectXを扱う事が一般的になれば顧客も視覚的な部分での要求が厳しくなり、業務系ソフトウェア
のレベルも必然的により高い技術力を要求される事になるだろう。







Copyright (C) 2001 A c t o r .N e t Soft Ware All Right Reserved