パスワードを忘れた? アカウント作成
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

C#言語、ISO標準獲得へ」記事へのコメント

  • ISO標準ってなにか意味があるのでしょうか?

    よく分からないのですが、今のところ.NETフレームワーク以外に使用されるようなことはなさそうですし、標準でなくていいからMSのほうで勝手にやっていてくれという感じです。

    ちなみに、

    C#に置き換わり、C++は廃れてしまったりするのでしょうか

    そんなことないと信じています。

    というか、C#ってC++

    --
    // Give me chocolates!
    • > ISO標準ってなにか意味があるのでしょうか?

      ISOになると、各国政府がある程度の後押しをすることになってます。

      例えば、おそらくJISにもなるでしょうし、情報処理技術者試験の
      選択科目にもなるかもしれません。さらにひょっとしたら、中学や
      高校の授業でとりあげられるかもしれません。

      今すぐの影響は
      • 30年どころか、100年たっても間違いなく生き残るであろう言語が少なくとも2つはあるでしょう。アセンブラとCです。

        これらの言語の特異な点は、言語のsemanticsに面倒な実行時の支援処理や初期化が一切含まれていないことです。すなわち、自分で作ったエントリポイントにいきなり処理を飛ばしてもきちんと動作するわけです。これは計算機をbootさせるためには

        • by rti (659) on 2002年10月15日 22時46分 (#183872) ホームページ
          私はそうは思いません。

          アセンブラについては CPU が存在している限り消えないでしょうが、
          C言語に関してはスレッドもサポートしていない言語が
          30年、100年後に生き残っているとは思えません。

          もし、残っているとしても、今の COBOL 並みの地位にいると思います。

          boost が取り込まれた C++ は生き残っていくような気がします。
          ただし、デスクトップというより、むしろ組み込み系、
          今のアセンブラ地位の言語として生き延びていくと思います。
          --
          by rti.
          親コメント
          • by brake-handle (5065) on 2002年10月15日 23時35分 (#183910)

            Cが今まで生き延びてきた、そしてこれからも生き延びていけるであろう本質は、後から追加が必要になった機能を全てlibraryに押し込めることができるためです。決して新しい機能のために言語の文法や意味論に手を加え、それゆえに過去のsourceを捨ててしまうようなことをしなかったのが強く効いています。その点では、threadingなんか1996年にとっくに実現されているのです。しかも、それ以前に作られたsourceを一切壊さずに。

            似たようなところでは、memory allocatorがあります。Cには汎用的なmemory allocatorとしての意味を持つ要素は一切ありません。高々stack上にとれる配列ぐらいです。これは実装が非常に簡単で、stack pointerの加減算ができればすぐに実現できます。一方、C++は汎用的なmemory allocatorの意味を持つnewとdeleteを定義してしまいました。したがって、C++を走らせる環境に応じてmemory allocatorを作り直さなければなりません。しかし、我々はいつでも4GBのだだっぴろい空間が使えるわけではありません。ページ数が限られているがゆえ、backing storeを作らなければ実用にならない環境にも直面します。わざわざそんな環境でまで、C++を走らせたいですか?

            Cがアセンブラとともに持っている専売特許は、環境への適応性です。memory allocatorなんかなくてもいい、単にRAMにloadしてentryへ飛び込むだけで実行できるプログラムを作れる言語がなければ、OSのような基本ソフトウェアは絶対に作れません。そもそも、メモリ管理をするプログラムをmemory allocatorが必要な言語で作ったりすることがタマゴとニワトリ問題を引き起こすので、そんなものを選ぶのはナンセンスですが。

            親コメント
            • >OSのような基本ソフトウェアは絶対に作れません
              BeOSはC++で記述されていたと思いましたが....。
              NeXTはObjective-Cで記述してたのでは?
              ま、どちらもCの記述がそのまま使えるから、要の所はCだ、と言われればそれまでですけど。
              親コメント
              • > >OSのような基本ソフトウェアは絶対に作れません
                > BeOSはC++で記述されていたと思いましたが....。
                > NeXTはObjective-Cで記述してたのでは?

                OSというよりはKernelについていいたかったのでは。
                BeではKernelコードではC++は使えないし、NeXTはmachカーネルですよね。
                親コメント
              • 要がCっぽいというのもありますけど、それ以上に注目すべきはそれらのOSで作られたcomponentが実際にはほかのOSでは一切役に立たなかったことでしょうね。片や完全にCで実装したMach VMはBSDにも移植できたというのに。

                C++だけじゃなくてオブジェクト指向の落とし穴なんですが、再利用性なんて形をきっちり決めただけじゃ全然実現できないんです。むしろ、外側から見える形に合わせて再利用元を変更するハメになったりして、本末転倒です。言語を設計する側にとってはもの作りのネタになりますが、その上で何十年も保守しなければならないものを作る側としてはまず採用できません。

                親コメント
              • >C++だけじゃなくてオブジェクト指向の落とし穴なんですが、再利用性なんて形をきっちり決めただけじゃ全然実現できない

                それ、OOが「害」になった、とまで強く言えるんでしょうか?

                もしそうでないなら、OOが有っても無くてもせいぜい同じ、という程度のことでしょうね。

                で、便利なものは使います。
                Vector(動的配列)「クラス」(のObject)が無かったらウンザリするよね、
                毎回似たようなコードを書いてたら日が暮れるよね、
                しかも似てるけど違う性質の(つまり兄弟の)クラスとかとも一緒に(=多態して)使いたいよね、
                とか言い出したら、せめてOOくらい無いと辛いですね。

                もちろん、辛かろうがどうしようが茨の道を歩む「自由」は有りますが。

                「再利用性」そのものの神話については、たしかにあれは神話でしかないですね。
                しかし、逆にいえば、OOを捨てたところで何かが楽になるわけでも無いわけで。
                それに、べつにOO(PL)だからって必ずガチガチの設計&再利用オタクに陥らないとならないわけじゃないです。

                >んです。むしろ、外側から見える形に合わせて再利用元を変更するハメになったりして、本末転倒です。

                そういうことはCだって生じることでは? Cに関数と構造体が有るからには、
                再利用性の問題は、クラス(関数と構造体と幾つかの追加オヤクソクの集成物でしかない)
                が有る言語と同じくらいに、ついて回るはずです。

                たとえば継承(再利用120%の世界)はイタイから必要最小限にしたほうがいい、ってのは
                OO内輪ですら既に言い尽くされた話です。OO人だってそれくらいの自衛策は心得てます。
                無策で取り掛かれば火傷するのは、どの言語や方法論(?)だって、同じ。

                稀に誤解してる人が居ますが、再利用といっても、実際にゃ大型や中型の部品は土台再利用しにくいんですよね。
                振り返って冷静に考えればCoding始める前から判りきってる事ではあるんだけど、
                システム全体のアーキテクチャに関わるような大きなObject(のクラス)は、一品物と思ったほうがいい。
                そして、逆に小さい部品の再利用性は、有効であることが多い。
                あたかもネジや釘のような小さくて「イロ」のついてない部品は再利用しやすい。
                ここを押さえていれば、再利用性自体は、そんなに御し難いものになったりはしない、んだけどなあ。

                大きな一品物をObject(Class)として作るのは、むしろ再利用性のためじゃなく、
                「そのほうがうまくまとまる物」であればObjectにするのが良いぞ、という感じだと思います。
                今自分が作ろうとしているプログラムがどういう性質のものであるか、によって決まると思います。
                ちょうど、ある処理を関数にする基準を、必ずしも「同じ処理の登場回数の多さ」だけで決めないほうがいい、のと同じです。
                #もちろん、小さい部品も、同じような調子で、Objectにするほうが似合うものと、そうでないものとがあります。

                余談:
                ところでC++以外のOOP言語は、どれくらい親しまれています?

                >その上で何十年も保守しなければならないものを作る側としてはまず採用できません

                それは変ですね。関数という部品の再利用は、(Cを使ってるからには)肯定されているのではないのですか?
                親コメント
            • >後から追加が必要になった機能を全て libraryに押し込めることができるためです。

              残念ですが全てではありません。
              上(?)で書いたように、Stackの使い方とかは処理系お仕着せになっちゃいますよね。

              ある実装のコンパイラのStackの使い方が不都合だからそれを捨てて違う実装を選ぶことは可能でしょうけど、
              それだってその処理系「の」お仕着せであるのは同じ。
              Cそのものの能力としてプログラマブルであるわけではないですよね。

              #俺のような、Cのたいした使い方をするわけでもない奴でも、時としてその「制限」が不快になります。

              そして、ここではたまたま「Stack」について書きましたが、
              そういうお仕着せによる制限は、C言語には、たしか他にも幾つかありますよね。
              確かにCは、お仕着せが他の多くの言語より「少なめ」ではあるんですが、「無い」わけではない。

              ここで「無い」なんて言い切っちゃうと、ほげ言語のパラドックス [dreamhost.com]の餌食になるのがオチです。

              >決して新しい機能のために言語の文法や意味論に手を加え、それゆえに過去の
              >sourceを捨ててしまうようなことをしなかったのが強く効いています。

              それは逆でしょう。
              Cが万能なのじゃなく、巷の多くのソフトが長年にわたって、Cの流儀にあわせてくれたんでしょう。
              Cでやれる範囲のことしかやらないようにしてきた、ということでしょう。

              Cは確かに万能ではなくても千能?くらいは有る言語なんで、そういう妥協をしても
              不都合が「あんまり」生じないわけですが、不都合は全く無いというわけじゃないです。

              >その点では、threadingなんか1996年にとっくに実現されているのです。しかも、それ以前に作られたsourceを一切壊さずに。

              #threadingって、(Multi)Threadのことですよね?違ったら御免。

              事情は全く知りませんが、それ、そういうものなのですか?
              96年という年は、Threadという"基本的な"ものが実装されるにしては遅すぎる時期であるような気がします。

              それに、「一切壊さず」ってのは無理が有りますよね。
              Threadが導入されればアプリ(など)側のアーキテクチャすら変わるのに、
              そのアプリ(など)のソースが無事でいられる筈が無いのでは?

              #そういやたしかちょうどその頃、そういうテーマの本を本屋で見かけた記憶が。
              #あの頃のイタイケな俺は驚いたもんだったけど、他の幾つかの言語を知った今となっては、もうあんまり驚けないな。

              >似たようなところでは、memory allocatorがあります。Cには汎用的なmemory allocatorとしての意味を持つ要素は一切ありません。

              というか、memory allocator「は」Cではライブラリとして提供「できる」機能(の1つ)ですね。
              他にも幾つか、Cにはそういう機能はあります。

              が、Cではライブラリの形態で提供できない機能「も」世の中には沢山有るわけで。

              たとえばLoopとかIfとか。

              また、前述のようにStackの使い方を変更したい場合があるので、「関数」という仕組み自体もまた
              場合によっては自作したりカスタマイズしたりライブラリ化したりしたいものですが、これも不可能ですよね。

              ここで「そんな機能を自作する必要は(滅多に)無い」という話をしてしまうと、
              Cの特徴もしょせんは程度問題だったのだということになります。

              >一方、C++は汎用的なmemory allocatorの意味を持つnewとdeleteを定義してしまいました。したがって、C++を走ら
              >せる環境に応じてmemory allocatorを作り直さなければなりません。しかし、我々はいつでも4GBのだだっぴろい空間が使え
              >るわけではありません。

              ん?そういうレベルの自作をアリだというならば、問題は簡単じゃありませんか?
              C++だって、とりあえず間に合う程度のお粗末なallocatorを作って与えればいい、ってことなのでは?

              >わざわざそんな環境でまで、C++を走らせたいですか?

              べつにCの後釜がC++でなきゃならんわけじゃないので、C++が不都合ならC++を捨てるまでです。
              つまりたまたまC++が例として不適切だっただけでは?
              親コメント
              • が、Cではライブラリの形態で提供できない機能「も」世の中には沢山有るわけで。
                たとえばLoopとかIfとか。

                制御構造がないのはプロセッサとして失格、マル。

                ん?そういうレベルの自作をアリだというならば、問題は簡単じゃありませんか?
                C++だって、とりあえず間に合う程度のお粗末なallocatorを作って与えればいい、ってことなのでは?

                あなたは恐ろしい人ですね、そのallocatorが実はOS全体で使うallocatorになってしまうことに気が付かないとは。

                OSの中でallocateする必要があるmemoryの大きさは、数十バイトから数GBまで非常に大きなばらつきを持っています。malloc(3)のように空のmemoryを持ってくるallocatorが実用になるのはせいぜい数十KBだけで、それ以上になると空きページを圧迫して性能を落としかねません。また、MB級になると全てを使い切らず、sparseにたたいていくことも増えてきます。

                そういう需要の方が実は性能に大きく響くことが分かっているから、複雑な機能を持つVMをいろいろ作ったわけです。仕様は後から変えると困る人が増えるだけに、単純にnewとdeleteで片付けているとひどい目に遭いますよ。

                親コメント
              • …schemeとかかじってみると分かるかも。
                #この議論だと割とG7、まともだと思うが
              • longjmp()とかあったよなあ…。newがメモリの確保に失敗したらNULLを返さずにexceptionを投げるように変わったなんてのもつい最近のことだしなあ。何かいろんな意味で現実と乖離した議論が続いているような気がする今日この頃。

                # ざっくりとしか追ってないのでAC
              • >「関数という仕組み自体を自作したりライブラリ化したり」ってなんのこっちゃ。G7たんは言語仕様って言葉わかってるか?

                若輩者な俺ですが敢えて言わせて頂くならば、
                「言語作ってみたことがあれば判りますよ。
                それも、Cとかみたいな有り触れた(ってのも変だが)言語とはあまり似てない言語を、ね。」
                です。

                勿論、洞察力のあるかたでしたら、わざわざ作るまでもなく理解可能かとも思います。
                つまり俺は作ってしまったわけですが(笑)。

                言語仕様ですか?
                それは、(現在の計算機で可能な)任意のかたちに「定義」可能です:-D。
                それとも、「関数という仕組み自体を自作」するような言語が
                現在の計算機で実現不可能だ、とでも思ってらっしゃる?

                よければLinkを書いておいた"PracticalScheme"頁を読んでおいてください。
                まぁあっちは俺も先日やっと知り始めた分野なんで受け売り100%ですが、
                逆にいえばそれだけ俺という劣悪フィルタを経由してません(ぷ

                >Cにスレッドが導入されたからって、スレッド使わないソースはそのままで問題ないだろ。

                あ。そうか。「使わない」部分の話だったのか。そう読めませんでした(^^;。

                >C#がJavaの出来損ないである

                それは嘘でしょう。出来損ない度でいえばJavaもC#も似たようなもんです。
                C#が流行り損なう可能性は否定しませんけど(笑)。
                親コメント
              • >制御構造がないのはプロセッサとして失格、マル。

                #プロセッサってなんですか?

                「ない」とは言ってませんけど。
                作ればいいしょ?と言っているのであって。
                #まぁ、毎回自作する事には意味は無いでしょうけど。

                >あなたは恐ろしい人ですね、そのallocatorが実はOS全体で使うallocatorになってしまうことに気が付かないとは。

                あれ?そういえば、C++のnewって、複数用意して使い分けることが出来るんじゃなかったっけ?

                #蛇足だがDelphiではNewInstanceというClassメソッド「を」多態することで同じことを実現できる。

                #蛇足2。Delphiは、メーカの言葉を信じるならば、Delphi自身と「アセンブラと」で作られてるそうな。C無し。
                ##Delphiを作るためにはCのStackFrame制限を回避する必要が有るそうなので、Cじゃ実際困るのでしょうね。
                親コメント
            • なんでこうチンケなアイデンティティを守りたがるかね?
            • そのころにはFORTRAN2100が制定されて大ブレイクになってたりして(w

              #「残すことが出来る」と「残っている可能性がある」は雲泥の差

UNIXはシンプルである。必要なのはそのシンプルさを理解する素質だけである -- Dennis Ritchie

処理中...