Ｃ＃ vs VB.NET〜．ＮＥＴ雑感〜

戻る

■ 導入

　さて、私も送ればせながら、この前 Visual Studio .NET というものを買ってみました。
　使ってみて、非常に使いやすいツールだと思いますし、おそらくは今後、この．ＮＥＴがWindowsの標準になっていくのでしょう。（※１）
　
　さて、．ＮＥＴを買ってみると、おもに３つの言語が入っています。
　それが、ＶＢ．ＮＥＴ、Ｃ＃、マネージＣ++の３つです。
　
　他にもＪ＃やＡＳＰ．ＮＥＴが入っていますが、これはJAVA経験者やサーバプログラミングをする人のためのものですので、
　とりあえず重要なのは、この３つの言語です。
　

■ Which?

　ここで、１つ疑問が湧いてくると思います。
　それは、どの言語を使うべきかという事です。
　
　もちろん、ＶＢ６を使っていた人はＶＢを使えばよいわけですし、Ｃ言語を使ってきた人は、Ｃ＃を使えば良いわけです。（※２）
　しかし、両方の言語を知っている人にとっては、少し悩むかもしれません。
　
　たいてい、両方の言語を知っている人というのは、「１：ＶＢから始めてＣ++に移行できた人」「２：ＶＢからＣに手を出して挫折した人」
　「３：学校でＣを習った」等の人が多いと思います。
　それで挫折した人は分かると思いますが、Visual C++ 6.0 は、非常に使いづらく、覚えにくいものでした。
　私なんかも、それが嫌でBorland C++（以下ＢＣＢ）に手を出したりもしましたが、結局長続きしませんでした。（※３）
　
（Ｃのポインタやクラスを覚えると、途端にＣ++が面白く感じはじめます。しかし、ＶＢのString型に慣れている人間にとって、char型やCString型は面倒すぎました。）

　
■ Ｃ＃は覚えやすいか？

　そこで、そういう人は、Ｃ＃に対しても同じ不安を抱くわけです。
　ＭＦＣのように複雑すぎないか、新しい言語ゆえに、低機能すぎないか、またstrcpyを使わないといけないのか‥‥など。
　
　しかし、．ＮＥＴについての本を読み、実際に使ってみてはっきりと感じました。
　ＶＢ．ＮＥＴとＣ＃は、ほとんど同じものです。
　
　‥‥などと書くと語弊がありますが、実際のところ、構文と一部のコマンド以外に違いはありません。
　例えば、C#に100の機能があるとすれば、VB.NETには99の機能があります。基本的に、（難易度は違いますが、）
　C#にできてVB.NETにできない事は、ほとんどありません。その逆も然りです。
　
　それも当然のことで、.NET FrameWorkは、そういう思想で作られているからです。
　今までの、VB6とVC6の間には、日本語とフランス語並みの格差がありましたが、VB.NETとＣ＃の違いといえば、
　文章を平仮名で書くかローマ字で書くか程度の違いしかありません。どのみち同じMSILに翻訳されます。
　
　
■ ＶＢは覚えやすいか？

　それでは、ＶＢはどうでしょうか？
　残念ながら、覚えにくくなっています。
　とりあえず、ここではＶＢ６がVB.NETになってから、明らかに使いにくくなっている点を挙げてみます。

　・完全にオブジェクト指向になったので、オブジェクト指向の知識がないと理解しにくい。
　・フォーム間のデータの受け渡しが、やりにくくなった。
　・PictureBoxの描画命令が、ＶＣ++でお馴染みのややこしいものに変更され、今までのものが全て使えなくなった。※４（重要）
　・Variant型が消えた。
　・FileListBoxコントロール、DriveListBox、DirListBoxの３兄弟が消えた。（それに代わる物は、．ＮＥＴでは提供されていません。）
　・MidB、LenB、RightBなどが消えた。（Unicode対応のため）
　・iniファイルに対応していない。（見捨てられた。）
　・GoTo文がない。（もっとも、ごく稀にしか使いませんが）
　・on Error GoTo も消えた。（例外処理に取って代わられた。）
　・Dim (2 To 5)ができなくなり、配列は全て０から始まるようになった。
　・コントロール配列が無くなった。
　・imageBoxが無くなった。

　ザッと見てこんなにもあります。
　しかし、これらの欠点は、Ｃ＃を選んでも同じです。つまり、.NETを使う以上は、これらの欠点を避けることができないのです。
　素直に諦めるべきなのかもしれません。
　

■ ＶＢは使いやすくなっているか？

　しかし、ＶＢが退化しているわけでは、決してありません。
　それどころか、ものすごく便利になっています。
　
　・Dim A,B,C,D,E As String　という宣言ができるようになった。
　・return 文で戻り値を返せるようになった。
　・しつこいぐらいにポップアップしてくる「構文エラー」が、おとなしくなった。（重要）
　・代わりに、誤りの箇所には波線が引かれるようになり、ひと目でエラーが分かるようになった。
　・A += 3 とか、 str &= "ああ" などが使えるようになった。（ただし、A++などは使えない。）
　・例外処理ができるようになった。
　・Dim N As Integer = 5 ができるようになった。
　・複数のコントロールのイベントを、同じプロシージャーに関連付けられるようになった。

　他にもありますが、とりあえずこんな感じです。
　

■ ＶＢとＣ＃の違うところ

　それでは、いよいよ本題に入りますが、まずは、ＶＢとＣ＃に対する誤解から解きたいと思います。
　ネット上でも、色々と誤解や偏見をみかけますが、これは言語を選ぶ上で、障害になります。
　まずは、それを取り除いてみようと思います。
　
誤解その１：VB.NETよりもＣ＃の方が速い

　昔から、「ＢＡＳＩＣは遅い」と言われて来ました。今ではマシンパワーも速くなり、そんなに気にならなくなりましたが、
　それでも「ＶＢは遅い」と言われ続けてきました。
　
　逆に、Ｃ言語は速いと言われてきました。コンパイルすると、ほとんど機械語に近いものになるのですから、
　速いのは当然です。
　
　しかし、Ｃ＃も速いかといえば、それは違います。それどころか、Ｃ＃の実行速度は、VB.NETと全く同じです。
　それもそのはずで、先ほども述べた通り、どちらも同じMSLIにコンパイルされます。
　.NET Frameworkでは、MSILしか受け付けません。なので、.NET Framework のマネージコードを使うのであれば、
　どの言語を使っても、実行結果・実行速度ともに同じです。VB.NETで書いてもＣ＃で書いても、コンピュータの耳には
　MSILに翻訳された形でしか届かないのです。
　
　
誤解その２：Ｃ＃はポインタが使える。

　と言っても、Ｃ＃でポインタが使えないわけではありません。が、Microsoftは、Ｃ＃でポインタを使うことを奨励していません。
　なぜなら、ポインタは使い方を誤ると、とんでもない事態を引き起こしてしまうものだからです。
　また、.NET Frameworkでは、常にガーベジコレクタというものが動いていて、メモリを整理してくれています。
　ガーベジコレクタは、ポインタが指し示しているアドレスの中身を変えてしまいます。なので、この２つを同時に使うことはできません。
　
　そういう理由で、Ｃ＃でポインタを使う場合は、関数の前に「unsafe」（安全でないという意味）のキーワードを書かされます。
　unsafeと書かないと、ポインタは使えません。そして、unsefeと記述するということは、そのプログラムが安全でない事を意味します。
　．ＮＥＴのウリである、「バグのない安全な」「スレッドセーフなコード」が、組めなくなってしまうのです。
　そして面倒なことに、「unsafe」と書かれている関数に於いては、メモリの確保＆解放をユーザが行わなければなりません。
　しかし、Ｃ++とＶＢの両方を使っている人には分かると思いますが、メモリの確保＆解放は、面倒臭い作業です。
　プログラムを「速く」開発するという観点から見ると、いちいちNew/Deleteを使うよりは、メモリの解放をガベージコレクタに
　任せた方が、開発効率が良くなります。
　また、コンパイラのプロパティも変えなければなりません。

　この通り、Ｃ＃におけるポインタは、非常に不自由なものです。これを「使える」と解釈していると、後で失望することになると思います。
　

誤解その３：VB.NETはランタイムが必要だから、Ｃ＃のほうがいい。

　これは大いなる誤解です。VB.NETには、今までのようなランタイムはありません。
　.NET Frameworkさえインストールしてあれば、動きます。
　そしてＣ＃も、.NET Frameworkがないと動きません。つまり、条件は全く同じです。
　ただし、.NET Frameworkは非常に巨大です。Microsoftからダウンロードできますが、手間も時間もかかります。
　まだ、気軽に作ったものを配布できるほど、普及はしていないでしょう、
　

■ それぞれの言語の欠点

　さて、双方の言語の優れている点を挙げるのは簡単です。が、そんなものはMicrosoftの宣伝文を読めば載っています。
　そこで、ここでは敢えて、両方の言語の欠点をあげつらい、貶めて比較する方法を取ってみたいと思います。
　
【ＶＢ．ＮＥＴの欠点】

　・コードの量が多い。
　　→Ｃ＃のコードでは、例えばサブルーチンは、｛ と ｝で括って示すことができます。
　　　Whileのループやif文の適用範囲も、｛ と ｝で簡単に示せます。
　　　一方、ＶＢ．ＮＥＴでは、いちいち「End If」「End While」を書かなければなりません。
　
　　　また、変数の宣言も、ＶＢ．ＮＥＴでは少し煩雑です。
　
　　　　Dim ABC As string.
　
　　　一方のＣ＃では、非常に記述が簡潔になっています。
　
　　　　string ABC;
 
　　　このように、文字の量が増え、読みにくくなる事は、ＢＡＳＩＣ言語の大きな欠点です。
　　　以下の２つのコードを比べてみて下さい。

'ＶＢの場合
Public Class HogeHoge Imprements System.Windows.Forms.Form
　　Dim Param1 As Integer
　　Dim Param2 As String
　　Private Function Syori(ByVal A As Integer, ByRef B As String) As Integer
　　　'処理内容〜〜〜
　　End Function
　　Private Property Prop1() As Integer
　　　　Get
　　　　　　Return Param1 * 5 + Param2
　　　　End Get
　　　　Set(ByVal Value As Integer)
　　　　　　Param1 = Value \ 5
　　　　　　Param1 = Value Mod 5
　　　　End Set
　　End Property
End Class		 //Ｃ＃の場合
public class HogeHoge: System.Windows.Forms.Form
{
　　int Param1;
　　int Param2;
　　private int Syori(int A,ref string B)
　　{
　　　　//処理内容〜〜〜
　　}
　　int Prop1
　　{
　　　　get
　　　　{
　　　　　　return Param1 * 5 + Param2;
　　　　}
　　　　set
　　　　{
　　　　　　Param1 = value / 5;
　　　　　　Param2 = value % 5;
　　　　}
　　}
}

　　　　ＶＢだと、どうしても文字が多くなり、横に長くなります。
　　　　また、この例ではクラスを使用していますが、PropertyやImprementsといった単語を覚えなければなりませんし、
　　　　演算子のオーバーロードもできません。

　・改行が厄介である。
　　→VBで、３行にわたって文字を表示させたい場合には、以下のように記述します。
　
　　　　　Label1.Text = "１行目" & vbNewLine & "２行目" & vbNewLine & "３行目"
　
　　　一方のＣ＃では、これだけで済みます。
　
　　　　　Label1.Text = "１行目\n２行目\n３行目";

（以下執筆中です。）

※１
　今までのやり方を使い続ける人もいると思いますが、Microsoftが意地を張った場合、「奨励されない方法」にされてしまう可能性があります。
　iniファイルがあっさりと見捨てられたように、今後のWindowsのバージョンUPにおいて、ＡＰＩを使った方法も捨てられる可能性があります。
　消えることはないと思いますが、隠蔽されたり、非常に使いにくいものになる可能性はあります。

※２
　マネージＣは、新規に．ＮＥＴプロジェクトを立ち上げるのには向いていません。マネージＣは難しく、Ｃ＃を覚える方がラクだという意見もあります。
　ＭＦＣも使えますが、これはＶＣ６と殆ど同じものです。

※３
　Ｃ++言語のクセの強さも原因の１つでしたが、ＢＣＢのクセの強さも原因でした。
　開発環境は重く、オートコンプリートが動くまで、1GHzマシンでも１秒かかります。カーソルがどこへでも行く（フリーカーソル固定な）上に、
　ＩＭＥ2003との相性も良くありません。マニュアルはMSDNに比べるとどうしても簡素ですし、入門者向けの市販の解説本は誤植だらけです。
　（なのに薄くて４０００円前後×２です。）
　非常に良い開発言語だっただけに、とても残念です。

※４
　いちいちキャンバスを取得して、ペンとブラシを宣言しなければなりません。しかも、描いたものは、ウィンドウを最小化するとすぐに消えてしまいます。
　うまく使うには工夫が必要で、オブジェクトについて色々と勉強しなければなりません。
　今までのような、Picture1.Line(12,3)-(100,200) などは使えなくなり、CLS命令も消えました。