たくさんの言語があふれていますが…

他に、標準ライブラリのmallocは、フリーリストチェーンでメモリ管理しているため、断片化すると、極端に性能が低下したはず。

Seiga Alisueさんの書き込み（2006-10-09 23:35）より：

【Visual Basic】
《欠点》
・構文が独特
・ネイティブコードを作れない

加えてVisual Basicを勉強すると『VB病（構文の独自性やコード数が少ないことなどによってほかの言語を習得する際に億劫になる病 - 命名、有末清華ｗ）』にかかってしまい、ほかの言語に移りにくくなる。

【C++/CLI】
《利点》
・マネージドコードを出力するからプラットフォームに依存しない（現状はWindowsのみ、ってか一生な気がする）

【Visual Basic】
・同じ.net frameworkで動くものとしてC#でできることができない場合がある。
【C#】
.net frameworkの全機能を利用可能

・必要な機能がすべて.net frameworkで用意されているわけではなく、変わったことをしたい場合事実上APIに頼った開発が必要となるがめんどくさい。

開発言語を比較する上で、比較の材料とされやすいのが言語仕様ですが、
実際には用途と環境も含めて考えたほうが良いと思いますよ。
それぞれの言語に得意分野・不得意分野があり、それに見合った用途が
あるのでそれで選ぶと良いと思います。そのために複数の言語があるので
あって、そうでなければ単一のメーカー(MSやボーランド等)が複数の言語を
わざわざ多額の開発費をかけてリリースしないと思います。

環境で考えられるのは、どれだけサードパーティが参入しているか、
日本全体(または世界全体)で開発者人数がどれくらいいるか、サポート
がどれくらいしっかりしているか、開発ツールが安定しており、
バグフィックスやバージョンアップも適度に行われているかという
ことです。

この手の話は、前提が曖昧だと収束しないと思うので、Seiga Alisueさんが
挙げた言語に絞った方が、Seiga Alisueさん自身が知りたい情報が多くなるの
ではないかと思いますよ。PHP、Perl、Rubyなど、スクリプト言語の元気が良い
ご時勢ですしね。利点、欠点も、用途によっては利点も欠点になってしまうこと
もあるので、どういった観点から見た場合の利点、欠点というのも提示された
方が良いですよ、話がブレなくなって。

がっつり最適化されたCのコードには勝てないが、そうでなければ勝てる見込みあり。
javaは実行時にHotSpotによって最適化をかけることができるので、プラットフォームに即した最適化を行えば、Cのコードといい勝負になるかもしれない。

まず構文について。比較している C++, C#, Java が、元々派生元が同じなので構文が似ているだけ。それらと派生元が違う VB を比較すると、構文が独特になるのは当たり前。COBOL（COBOL.NET）や FORTRAN, Prolog, LISP などは、ご存じ？PL/SQL などやると、また面白いことになるんだけど。

次、ネイティブコード。少なくとも、VB 6.0 では Windows ネイティブコードが生成されます（Delphi 対策）。もっとも、VB.NET になって、共通言語になっていますから、もう一度コンパイルするという意味で、ネイティブコードではなくなっていますが、それを言っては C++/CLI, C# も同じ。

引用:
【Visual Basic】 ・同じ.net frameworkで動くものとしてC#でできることができない場合がある。 【C#】 .net frameworkの全機能を利用可能

ここ、意味がわかりませんでした。いったい、なんのこと？

CLI は、OS を提供するのではなく、ソフトウェアの実行環境を提供するものなので、CLI の基盤である OS の状態を知るには、当たり前のことだと思いますが？
　ってか、System.Windows.Forms が、Windows 完全依存なのに、.NET Framework の中に用意されているのが、あるいはおかしいのかも。System.XWindow 名前空間を用意しろって？

Seiga Alisueさんの書き込み (2006-10-10 22:39) より:

1, Windows開発者なので開発環境はWindowsで、加えてIDEがあるものとして考えさせてもらいます。（結果Visual Studioがあるものとして）
2, 新しい言語が出てきてもわからないので VB C++(C++/CLI) C# Javaに限定して教えて（論議して）もらいたいです。
3, ローカル・ネットワークと状況を分けて利点欠点あげてもらえるとわかりやすいかも、ネット上で使うものとローカルで使うものは違いますしね。
# そういえば将来ローカルで使用するソフトウェアがネット上から利用できる形になってインストールとかが必要なくなるんじゃないか？　という話を聞いたことがありますが、あれはJavaのことを強く言っていたものですよね？実際問題セキュリティなどもありますし無理なような気がしますが。

こんな感じでお願いしますm(_ _)m足りないところがあれば付け足します。

引用:
まず構文について。比較している C++, C#, Java が、元々派生元が同じなので構文が似ているだけ。それらと派生元が違う VB を比較すると、構文が独特になるのは当たり前。COBOL（COBOL.NET）や FORTRAN, Prolog, LISP などは、ご存じ？PL/SQL などやると、また面白いことになるんだけど。

たしかにそうなんですが、実際いま『Windows用ソフトウェア作成』で使われている言語の中で言えば独特なのでは？と、僕が『Windows用』って言ってなかったのがすっごく悪いんですけど（苦笑…。ちなみにCOBOLやFORTRAN,LISPは名前だけなら…という程度（汗。

Visual Basic.netを使わないので具体的な例ってのが挙げられないですが、C#は.netframework用に作られた言語なので全機能を利用できるがVBは構造上できない機能があるって聞いたことがあります。機能ってわけじゃないけどVBじゃunsafe使えませんしusingもなかったはず（新しいので使えるようになりましたっけ？）

利用者側としてはたとえばMIDIの処理・MP3の処理などファイル的には基本的にOSに依存しない（しないですよね？）ものの処理などもAPIを使ってやらなきゃいけないので、できれば

もちろんゲームならCとかアセンブリ（相当古いけどFF7はアセンブリに似た独自言語だったとか、昔聞いてびっくりした覚えがある、相当書きにくいだろうなぁって - 使用言語VB時代）

利用者側としてはたとえばMIDIの処理・MP3の処理などファイル的には基本的にOSに依存しない（しないですよね？）ものの処理などもAPIを使ってやらなきゃいけないので、できれば

PlayMidi って関数が.net frameworkで用意されていて、内部的にWindows用の.net frameworkならWindowsAPIを呼び出してマック用ならマック用の関数か何か（マックってAPI？？？）を呼び出すみたいに、プラットフォームが変わっても.net frameworkが処理の変更の面倒を見てくれるといいなと。

Seiga Alisueさんの書き込み (2006-10-10 22:39) より:

たしかにそうなんですが、実際いま『Windows用ソフトウェア作成』で使われている言語の中で言えば独特なのでは？と、僕が『Windows用』って言ってなかったのがすっごく悪いんですけど（苦笑…。ちなみにCOBOLやFORTRAN,LISPは名前だけなら…という程度（汗。

【Visual Basic】
・同じ.net frameworkで動くものとしてC#でできることができない場合がある。
【C#】
.net frameworkの全機能を利用可能

C#は.netframework用に作られた言語なので全機能を利用できるがVBは構造上できない機能があるって聞いたことがあります。機能ってわけじゃないけどVBじゃunsafe使えませんしusingもなかったはず（新しいので使えるようになりましたっけ？）

Jittaさんの書き込み (2006-10-10 23:18) より:

少なくとも、COBOL については COBOL.NET というものもあり、Pascal については Delphi.NET というものもあり、VisualStudio 上でコーディングできるかどうかは知りませんが、Windows アプリケーション開発用として、存在しています。