- - PR -
「C++/CLI」で思う事
1|2|3
次のページへ»
投稿者 | 投稿内容 | ||||||||
---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2006-10-04 12:42
objectです。
C++/CLI(ECMA-372)がISOに承認されなかった様ですね。 #私も「C++/CLI」に関しては、少しづつ勉強はしているのですが。 「C++/CLI」に 「gcnew」 が追加されています。 でも、「C++/CLI」の本質は、 「C++」を「マルチプラットフォーム対応」にする事 ではないでしょうか? この問題は、本当に 「new」に「限定的に具体化した gcnew を追加する事」 で、解決出来る問題なのでしょうか? 例えば、 同時に存在する「プラットフォーム」が3個以上になった場合は、どうするのでしょうか? 問題は、「new」の操作対象である 「名前空間」に限界がある事 だと私は考えています。 「プラットフォーム」が明示されていない「名前空間」は意味が無い 逆に、 「名前空間」は、「プラットフォーム」が指定されて初めて意味を持つ という事だと思います。 従って、重要且つ求められているのは、 「gcnew の追加」 ではなく、 「プラットフォーム」と「名前空間」を「統一的に記述・処理」出来る事 なのではないでしょうか? ※「統一的に記述」を「統一的に記述・処理」に変更しました。 [ メッセージ編集済み 編集者: object 編集日時 2006-10-04 13:13 ] | ||||||||
|
投稿日時: 2006-10-04 13:18
こんにちは。
新しい試みで、意訳してみました。 前提 C++/CLIの本質は、C++をマルチプラットフォーム対応にする事である。 主張 C++/CLIは、プラットフォームと名前空間を統一的に記述・処理できるように改善するべきだと考える。 根拠 1)プラットフォームが明示されていない名前空間は意味が無い。即ちマルチプラットフォーム対応とは言えない。 2)マルチプラットフォーム対応と言えない現状では、前提に示した本質を満足していない。 | ||||||||
|
投稿日時: 2006-10-04 23:59
C++/CLIに思うことは、どう考えても「標準」には成りえないことです。
ごちゃまぜ言語で、ある意味使いやすいけど、 仕事で使うなら勘弁してほしい 趣味ならいいのかもしれない。 ぐらいしか思いませんでした。 私の場合は、そもそも「C++/CLI」はMicrosoftのためだけにあるから、 標準化する必要がないと思っているのですが。。。 >「C++/CLI」の本質は は、「C or C++ or C# or Javaで、文法ごちゃ混ぜなまま、思ったとおりに記述するとコンパイルできて動作できる」 ことだと思います。 あの言語文法と使用方法を見て「標準化」に掛ける理由がよく分からない。。 「System」ってなんぢゃい、というのはむしろ終わりの方の疑問で。 >「プラットフォーム」と「名前空間」を「統一的に記述・処理」出来る事 もはやそんな問題ですらない気がする。。。 C++/CLIにするなら、D言語にしたいな。。。と思ってるのですが。 | ||||||||
|
投稿日時: 2006-10-05 18:01
objectです。
========== >加納正和さん >C++/CLIに思うことは、どう考えても「標準」には成りえないことです。 >‥‥‥‥‥‥ >私の場合は、そもそも「C++/CLI」はMicrosoftのためだけにあるから、 >標準化する必要がないと思っているのですが。。。 そうですか。 でも、「MS」に於ける「.NET」の状況を考えると 「C++/???」という言葉で象徴される言語の存在意義はある のではないでしょうか? #只、「???=CLI」が「CLI」に特殊化せず、一般的な形で組み込まれる必要があると思います。 >「C++/CLI」の本質は、 >「C or C++ or C# or Javaで、文法ごちゃ混ぜなまま、思ったとおりに記述するとコンパイルできて動作できる」 >ことだと思います。 「CLI」自体が、「C#」で象徴されるものです。 従って、 例え、「C#、Java」と共通するものが、言語として存在しても、 「C++/CLI全体がシッカリ分析・設計されたものであれば良い」 と私は思います。 >あの言語文法と使用方法を見て「標準化」に掛ける理由がよく分からない。。 これは、「言語文法・使用方法」以前に 「MS」が「C++自体のマルチプラットフォーム対応」を必要としている。 そして、出来れば 「特殊なC++にしたく無い」 という事だと私は理解しています。 >C++/CLIにするなら、D言語にしたいな。。。と思ってるのですが。 私は、 「どの言語を選択するか」 という問題では無く、 一つの言語を如何に「マルチプラットフォーム化」するか という問題だと思います。 従って、 「D言語」でも、もし「マルチプラットフォーム化」するのであれば、 同じ問題が生じるのでは無いでしょうか? ========== >ALL 少し厳しく聞こえると思いますが、 私が、 「gcnewというキーワードの導入」 によって直感的に感じたのは、 一つの言語(C++/CLI)としての「分析(抽象化)」が殆ど出来ていないのでは? という事でした。 #つまり、やっているのは設計だけで、細かい部分の辻褄合わせをやっている? #「現在のC++をベース」に「特殊(異)なC++」を考え、それを「C++」に加える事で対応しようとしている? #言語の拡張の仕方としては、特異だ(つまりC++的では無い)と思います。 #簡単に言えば、この言語の拡張の仕方は「VB」的? 恐らく、「gcnew」の導入によって、「CLI」を位置付ける限り、 「C++/CLI」が「C++/???」の観点から認められる可能性は余り無いのでは? と私は思っています。 #それから、名前空間を拡張をした場合「C++/CLI」に新たな観点が現れる可能性があるのではないでしょうか? | ||||||||
|
投稿日時: 2006-10-05 19:34
そうなんですかね? ただ単に「C++」を「CLI」に対応させたいんだけど、 アンマネージコードの出力機能は切れないのでそういうものになった ってことじゃないんでしょうか。 あらゆる言語からの出力をCLIに集約するのが要点じゃないのかな | ||||||||
|
投稿日時: 2006-10-05 20:01
ここで「マルチプラットフォーム」は、マイクロソフトでの「マルチプラットフォーム」、つまり、Windows OS だけを対象としている、、、というのがミソかも。 _________________ | ||||||||
|
投稿日時: 2006-10-06 02:56
なるほど、するとマイクロソフトのスタンスは ・プラットフォームは「CLI」を推進するが、Win32、COMなどの互換性は維持する。 ・マネージドコードをわざわざ「C++」で書くことを進めはしないが、作成できる必要はある。 ・アマネージドコードを作成する言語としは「C++」を残す。 というあたりだと思うので、今の「C++/CLI」がちょうどいいですね。 標準化については政府調達への対応などマーケティング上の理由じゃないかな。 というか、ECMAへ提案ってのを見るとこれしか思い浮かばなくなってます。 | ||||||||
|
投稿日時: 2006-10-06 03:37
過去の混乱を収集するために「がんばってますよ」ってパフォーマンスって気もしますね。 #qtとgtkが混在したコードなんて考えただけでゾッとします。 |
1|2|3
次のページへ»