- - PR -
「C++/CLI」で思う事
| 投稿者 | 投稿内容 | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2006-10-08 00:06
「悪意」という言葉が不適切であったことは認め、謝ります。ごめんなさい。
良い言葉が出てこないのですが、「いたずら心を持って」とか、「皮肉を込めて」とか、「おとしめる」という意味ではなく、まぁ、そういうつもりで用いました。 なぜか。 私は、.NET Framework が、今のところ Windows でしか動作しないことを知っています。mono プロジェクトというものもありますが、ASP.NET 限定であり、System.Windows 名前空間については、Windows 専用になっています。
というところが、そのことを意識しているように感じました。 また、『問題は、「new」の操作対象である「名前空間」に限界がある事だと私は考えています。』のあたりも、全く意味不明（名前空間を操作する new って、どういうこと？）ですので、うんちくを含んでいることが予想されました。 この辺から、何らかの反応があれば、それに対して、インターフェイスの時や VB の問題の時や、何とかさんの思想論や、and so on な展開になるんじゃないか、という危惧があります。 PM でもお伝えしましたが、例示したことに対して他人が共感してくれないなら、その例に固執するのではなく、他の、共感が得られるような例を探すべきかと思います。 『貴方が、誤解をしない努力を全く行っていない』とおっしゃるなら、私は、「あなたが、他人を誤解させない努力を全く行わないなら」と、返したいと思います。 ここは、誰かの主張をウンウンと聞く場所ではないと思います。 誰かの主張と、他の誰かの主張を、互いに共通する部分を探りながら、お互いに理解を歩み寄らせる場所だと思います。 これまでのobjectさんの投稿からは、あなたから他の人に歩み寄ろうという姿勢を感じることができませんでした。 このとこは、あなたが『誤解をしない努力』と表現することを、助長していると思います。 たとえば、私はどこかで、行頭 # を「読み飛ばし」と表現しました。これは、UNIX シェルに対して読み飛ばし、スクリプトを読む人にとってはコメントである # から始まっているからです。読み取る主体であるシェルにとっては読み飛ばしですから、掲示板での読み取る主体である人にとって読み飛ばしという意味で用いたのですが、共感が得られませんでした。 そのため、それ以降は使わないように意識しています。で、先の "rem" とか使ってみたりしているわけです。 が。 私は以前のスレッドで、「コメントで語るのは、読みにくいのでやめて欲しい」と書いたと思います。しかし、あなたは依然として、行頭 # の行で解説を行っています。 また、『読みやすい長文と、読みにくい長文があるよね』という投稿があったと思います。これは、対象を示していないので、どっちがだれとは言えませんが、私にとってobjectさんの投稿は読みにくいです。 というのは、意図を持って改行をされているのだと思いますが、その改行が文意の切れ目だとは思えないので、どんな意図を隠しているんだろうということを読み取るのに、非常に疲れます。 ブログの方のコメントで書きましたが、スレッド全体の流れとして考え場合と、個々の投稿だけを考えた場合で、文意が異なっているのではないか、つまり誤解しているのではないかと思えることがあります。 そういうことを考えながら読むのは、非常にしんどいです。 できるだけ、他人に誤解を与えない書き方をしていただきたいと思います。 _________________ | ||||||||||||
|
投稿日時: 2006-10-08 01:27
傍観するつもりだったのですが、気になったことがあったので発言させていただきます。
私は、C++/CLIに関して「批判的」です。 なぜなら、MSに所属する資産と、オープンソースで展開されている資産を同一視出来ないからです。 また、マルチプラットフォームがもたらす物は革命ではなく混乱ではないかと危惧しているからです。
この主張については、対等な立場であるなら当然の権利と思います。
あくまで、Jittaさんの「主観的」発言と理解しましました。 ただ、過去の発言でObjectさんが「一方的と思われるような発言をしてきた為」と主張されているようです。 先にも言ったように立場が対等であるなら、同等の権利と責任を有するはずです。 その事を御理解頂きたいものです！ # 途中、理解不能な所は省略させて頂きました。御了承ください。 | ||||||||||||
|
投稿日時: 2006-10-08 02:36
私の思うところはこんなんです。
【「C++/CLI」をISO標準にしたい】ということなら その必要はない。 マイクロソフトがマイクロソフトのプラットフォームの為に拡張した「C++」を 標準化する理由がマイクロソフト以外の者にとってはないでしょう。 ISOが承認しなかった理由に表向きにどんな内容をあげているにせよ、 第３者からみれば当然の結果に思います。 ISOは次期「C++」として「C++0x」の標準化作業もしているみたいですし、 マイクロソフトから提案があるのなら、「C++/CLI」をまるごと標準化ではなく、 こちらに拡張項目を提案するというアプローチもあるのではないでしょうか。 （もしかすると実際に何らかの提案をしているかも知れません） といっても「C++/CLI」は既に実装されている使用されているものなので、 マイクロソフトがこれを積極的に行う理由は私には思いつきません。 【「C++/CLI」をさらにプラットフォームに対して汎用的な言語に改訂しよう】という話でも 必要ない。 「C++/CLI」は今の「C++/CLI」が一番よいと思います。 私はプログラミング言語の設計にプラットフォームを考慮する必要はないと思います。 対応するプラットフォームについて考えるのはコンパイラの作成者が考えることで、 コンパイラ作成者があるプラットフォームに対するコンパイラを作製するときに、 言語の独自拡張が必要になった場合、それを行うのは当然で「C++/CLI」に限らないことですね。 「C++/CLI」をさらなるプラットフォーム（Objectさんがどんなのを想定している のか分かりませんが）に対応するように汎用化する設計変更を行った場合の結果は ・既存の互換性を維持するため、言語がより複雑になる。 ・言語が複雑化しないように汎用化する代わり、プラットフォーム側での対応が 必要になる。 のどちらかになると思います。 これらの結果は誰も望まないものなのではないでしょうか。 以下、余談 次なるプラットフォームの拡張ってなにがくるんでしょう？ 「CLI」のマルチコアかとか？ ライブラリが大型化し抽象化が進んで、VisualStudioやVBAマクロの IDEが「Squeak」みたいになってたりすると面白いかな。 今後５０年くらいの流れは、「C#」がアンマネージドコードを出力できるように拡張し、 ネイティブコードへのコンパイルが必要なプログラムも「C#」に緩やかに移行、 「C++/CLI」は「C++0x」対応の拡張をしつつフェードアウトって感じかなぁと予想しています。 それと、自分の考えを正確に伝えようとする努力と相手の考えを正確に読み取る努力ですが、 その話題に対して、お互いに掛けても良いと思える範囲の努力で良いじゃないですか。 その中で何か面白いことが有れば嬉しいし、無くてもまぁしょうがないでしょ。 | ||||||||||||
|
投稿日時: 2006-10-08 06:24
http://e-words.jp/w/CLI.html インフラストラクチャでした。 _________________ | ||||||||||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。