- - PR -
他言語と比較したC#の特徴について
投稿者 | 投稿内容 | ||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2002-04-11 00:28
Delphi Pascalですか!なるほど〜。
私はDelphiに関してはあんまり知らないのですが、プロパティ、インデクサ、デリゲート、イベントをサポートしていたんですね。これはえーと・・・もともとPascalが持っていた概念だったのでしょうか?それともDelphiとしてサポートされるように言語が拡張れたとか?興味深いですね。ひょっとしたらもっと古い言語で既にこれらの概念が存在していたら、凄いことですね。 逆にC#は、言語として(実装は別にして)改良の余地があるのでしょうか? #出たばっかりなのに気が早! | ||||||||||||||||||||
|
投稿日時: 2002-04-12 12:08
GUIDに関しては、COMの技術と考えない方が、私は良いと思います。確かに、clsidとしてGUIDを使用するのはCOMなんですが、オブジェクトをアイデンティファイするIDとして、使ってる人は多いんじゃないでしょうか? それから、「すえぞう」さん、返答が遅くなって済みません。 誰かもっと「Delphi」に詳しい人の投稿があるかと思ったのですが、無いですね。 少しだけ、私なりに説明します。(でも、間違ってる所があったら、許して下さいね。) そうです。Borland の「Object Pascal」です。 「Object Pascal」としては最も進んでいると思います。 -------------------------------------------------------------------------------- プロパティ: 「C#」よりは、レベルが高いと思います。オブジェクトの永続性と密接に絡んでますから。 プロパティに関する説明を全てここでするのは無理だし、出来ないので、記述例だけにします。 ただ、永続性に関して言えば、「Delphi」の場合、IDEでドラッグ&ペーストによって配置したコンポーネントはインスタンスの定義だけが先頭のpulish領域に作成され、それらのコンストラクト処理は、リソースから自動的に行われます。 したがって、コンストラクト、設定処理を行う文は、何処にも存在しません。 オブジェクトが相互に参照し合ってる場合も完全に解決してくれます。 例)
インデクサ: 配列プロパティの定義の後には default 指令を続けることができ,その場合,その配列プロパティはクラスのデフォルトプロパティになります。これがインデクサに相当すると思います。 例)
デリゲート: キーワードとして「delegate」がある訳ではありません。 メソッドポインタの定義です。 例)
イベント: 例)
こんな感じです。 少しでも、何かのお役に立てばと思い、精一杯書いてみました。 私は、そんなに詳しく無いので、もし間違ってたら、許して下さい。 そして、誰か修正、補足をお願いします。 | ||||||||||||||||||||
|
投稿日時: 2002-04-12 14:00
ちと、皆様に質問です(今一つこの会議室の内容と食い違っている部分もあるのですが)。
「Microsoft Visual C++」という「言語」が、あるのでしょうか? ちなみに、私は普段はUNIX系のプログラマです(いえ、Windowsでのプログラム経験もありはするのですが)。 自分が認識している限りにおいて、 ・C++という言語で ・Win32APIがあり ・MFCがあり ・STLがあり(…あったと思うのですが、WinodwsではもっぱらCプログラマなのでちと不安...) という環境下において、ヴィジュアルに開発できる環境が「Microsoft Visual C++」という「製品である(統合開発環境である)」、と認識しているのですが。 言語の話をするので、言語周りの話をきちんと定義しておかないと、ちとやり取りが不安なので。 ーーー で、C#の話ですが。 言語仕様的にはまぁ色々賛否両論あると思うので難しいのですが。好みからすると今一つ。ただ、やれば普通に組める言語仕様だとは思います。で、好みってのはあまりにも主観的なので、その辺はあまり言及しません(簡単に言うと、例えばswitch文でbreakを使わなくていいとか、あの辺が好みではない-細かい話ではありますが-)。 もう少し気になるのが「現実にどのくらい使えるのか」です。 自分は現在フリーのSEなので、その辺はわりと直接お仕事と収入に直結するので。 一番気になるのが「(少なくとも現在は)Windows系のプラットフォームにしか乗らない」事です。いやまぁここで「ビジネス環境でのWinodesというOSについて」の議論は避けますが。 ただ、プラットフォームが限定されると、それだけ勉強にコストがかかるぶん、リスクが増します。 無論、本当の意味での「マルチプラットフォーム」など存在せず(Javaだって、十分OS毎に挙動が変わります)、したがって、この場合「度合い」となるのですが。 C及びC++は(普段の自分のメイン言語)、文法をしっかり学ぶと、結構つぶしがききます。Windowsアプリを組まないといけなかったときも、Win32APIをおお慌てで読み、どうにかなりました(数多くある「変な癖」には相当なやまされましたが)。 Javaは、まぁ概ね。コードレベルでの互換性はそこそこあると思います。 CGIでたま???に使うPerlは、認識している限りでは、それなりに。もっとも、Windowsでバッチ処理をすること自体がめったにないので、という状況ではありますが。 デルファイ(ふだん使わないからスペリングすら覚えてないや )とかに関してはわからんです。 で、肝心のC#ですが。 現状、UNIX環境ではあまり「使える状況」が見えないんですね。で、現在のM$とかのスタンスを見ても、積極的にUNIX環境にどうこうしよう、という意思が見えない。 かつ「Java to C#」、「C# to Java」なんてものがあるらしく(未確認)。 この辺を考えると、「コスト(時間)を払ってまで学ぶ言語」としては、もう一つ押しが弱いかなぁ、と。 その辺の、ビジネスまで込みで「C#サイコー」って言う人のご意見とか、聞いてみたいです。出来れば「自分はWinodws系しかやらないから」などの理由ではないところで。 | ||||||||||||||||||||
|
投稿日時: 2002-04-12 15:04
気になったので一点だけ(それこそ細かいんですが)
-------------------------------------------------------------- (簡単に言うと、例えばswitch文でbreakを使わなくていいとか、 あの辺が好みではない-細かい話ではありますが-)。 -------------------------------------------------------------- C#ではswitch文の中では必ずbreakとかgotoといったジャンプステートメントが 必要です。 | ||||||||||||||||||||
|
投稿日時: 2002-04-12 16:23
念のために補足しますが、プログラム言語にはライフサイクルがあります。 生まれて、成長して、成熟して、少しずつ消えていくというサイクルがあります。 C/C++は、完全に成熟した言語で、社会の各方面で使われており、それに対するお仕事があるのは当たり前です。 それに対して、C#はまだ生まれたばかりで、成長期にすら入っていません。そういう意味で、今すぐC#を使った仕事が世の中にどれほどあるかといえば、ほとんど無いでしょう。しかし、今仕事がないことと、C#が成熟期に入ったときに仕事あるかという問題は別物です。 実際、C++も、誕生期には「何それ?」「金にならない」という状況でした。 単なる仕事の道具なら、少なくとも成長期に入ってから手を出せば十分でしょう。
C#は、ECMAの標準になっているので、WindowsやMSに限定されることはないと思います。実際、オープンソースのC#コンパイラの開発は進んでいます。(どうも複数あるらしい)
私はC#の良さとは、つまるところコストだと思います。同じ機能のコードなら、C#で書いた方がC/C++よりずっと短い時間で作れるので、安上がりだと思います。もちろん、現実の世の中は複雑に絡み合っているので、現場では単純にそうなるか分かりませんが。 [ メッセージ編集済み 編集者: autumn 編集日時 2002-04-12 16:28 ] [ メッセージ編集済み 編集者: autumn 編集日時 2002-04-12 16:28 ] | ||||||||||||||||||||
|
投稿日時: 2002-04-12 20:17
引用:
-------------------------------------------------------------------------------- 第四に、お金になるコードのほとんどは何らかのI/Oがボトルネックになるので、コードの最適化は大してお金になりません。 -------------------------------------------------------------------------------- これは鋭い考え方ですね。DBMSではI/Oコストを安くするのが原則です。しかし、IMDBのようなメモリではそれは必ずしも正しくなく、ロック競合の最小化、あるいは並列処理の最大化がより重要です。これもお金になります。 引用: -------------------------------------------------------------------------------- 単一のプログラム言語ですべての問題領域に立ち向かおうとする試みは、PL/Iですでに破綻したと思います(いや、そう教わりました、私は)。そのような言語を作るのは不可能であるだけでなく無意味です。 -------------------------------------------------------------------------------- 同意します。が、70年代には言語構文自体に拡張機能を持たせて問題を解決するアプローチがありました。メタオブジェクトなどです。それは、失敗しましたが。その後、OS上の仮想マシンにそのようなプロトコルを載せる考えになり、それが現在のCTSのような共通タイプシステムとなり、拡張性は仮想マシン上にあるフレームワークが担う形態になった歴史があります。さらに、C++など単一言語内に複数のパラダイムをとり、かならずしも複数言語で問題を解決する方法にとらわれず、言語に依存しない問題解決手段もありえます。これがマルチパラダイムの考え方です。 引用: -------------------------------------------------------------------------------- C#ではswitch文の中では必ずbreakとかgotoといったジャンプステートメントが 必要です。 -------------------------------------------------------------------------------- これはコードブロックの途中にジャンプすることに制約を加える安全な構文です。CLIのタイプシステムの制約にはなく、C#が安全性のための制約を加えたものです。 | ||||||||||||||||||||
|
投稿日時: 2002-04-12 21:16
なるほど。実は先日C#でいわゆるソケットプログラム(NTサービスとして稼動)を作るプロジェクトに首を突っ込んだんですが、多数のクライアントをさばきつつ、(独自の)プロトコルにおけるタイムアウトやSuspend/Resumeセマンティクスなどの処理を適切に行う、「prettyな」仕組みが結局作れませんでした。delegateでGOFのStateパターンのモドキを作るところまではいいのですが、そこから先がどうも...。このようなフレームワークをCLR上に作り出せれば、確かにお金になりそうです。
そこで、 C#、あるいはMC++にはインラインILが必要だと思うときがあります。最適化のためというよりも、欲しい機能を補うためというか。タイプセーフティを維持しつつどこまでできるのか、ちょと疑問なところもありますが。MC++ならverifiableじゃないのでいいかもしれませんね。 | ||||||||||||||||||||
|
投稿日時: 2002-04-12 21:42
引用:
----------------------------------------------------------------------- そこで、 C#、あるいはMC++にはインラインILが必要だと思うときがあります。 ----------------------------------------------------------------------- 埋め込み型言語はSQLなどが有名ですが、こういった実装ではpreprocessorでやるか、コンパイラ本体でやるかなどの選択肢があります。マイクロソフトにはX#という言語があり、XMLベースworkflow定義をmanagedコードに埋め込むやり方があります。私は好きではないですが。そういえば、VC++ 6.0ではCOM IDLを属性ベースでC++に埋め込むやり方があった。いまの.NETのカスタム属性の原型です。あれも、インターフェイスと実装の分離の原則をわかっている実装者なら利用してもいいけど、あの構文を許すかどうかは賛否両論があります。 |