アカウント名:
パスワード:
C#に置き換わり、C++は廃れてしまったりするのでしょうか
そんなことないと信じています。 というか、C#ってC++
30年どころか、100年たっても間違いなく生き残るであろう言語が少なくとも2つはあるでしょう。アセンブラとCです。
これらの言語の特異な点は、言語のsemanticsに面倒な実行時の支援処理や初期化が一切含まれていないことです。すなわち、自分で作ったエントリポイントにいきなり処理を飛ばしてもきちんと動作するわけです。これは計算機をbootさせるためには
Cが今まで生き延びてきた、そしてこれからも生き延びていけるであろう本質は、後から追加が必要になった機能を全てlibraryに押し込めることができるためです。決して新しい機能のために言語の文法や意味論に手を加え、それゆえに過去のsourceを捨ててしまうようなことをしなかったのが強く効いています。その点では、threadingなんか1996年にとっくに実現されているのです。しかも、それ以前に作られたsourceを一切壊さずに。
似たようなところでは、memory allocatorがあります。Cには汎用的なmemory allocatorとしての意味を持つ要素は一切あ
が、Cではライブラリの形態で提供できない機能「も」世の中には沢山有るわけで。 たとえばLoopとかIfとか。
制御構造がないのはプロセッサとして失格、マル。
ん?そういうレベルの自作をアリだというならば、問題は簡単じゃありませんか? C++だって、とりあえず間に合う程度のお粗末なallocatorを作って与えればいい、ってことなのでは?
あなたは恐ろしい人ですね、そのallocatorが実はOS全体で使うallocatorになってしまうことに気が付かないとは。
OSの中でallocateする必要があるmemoryの大きさは、数十バイトから数GBまで非常に大きなばらつきを持っています。malloc(3)のように空のmemoryを持ってくるallocatorが実用になるのはせいぜい数十KBだけで、それ以上になると空きページを圧迫して性能を落としかねません。また、MB級になると全てを使い切らず、sparseにたたいていくことも増えてきます。
そういう需要の方が実は性能に大きく響くことが分かっているから、複雑な機能を持つVMをいろいろ作ったわけです。仕様は後から変えると困る人が増えるだけに、単純にnewとdeleteで片付けているとひどい目に遭いますよ。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
UNIXはシンプルである。必要なのはそのシンプルさを理解する素質だけである -- Dennis Ritchie
ISOってなんか意味あるの? (スコア:2, 興味深い)
よく分からないのですが、今のところ.NETフレームワーク以外に使用されるようなことはなさそうですし、標準でなくていいからMSのほうで勝手にやっていてくれという感じです。
ちなみに、
そんなことないと信じています。
というか、C#ってC++
// Give me chocolates!
Re:ISOってなんか意味あるの? (スコア:1)
ISOになると、各国政府がある程度の後押しをすることになってます。
例えば、おそらくJISにもなるでしょうし、情報処理技術者試験の
選択科目にもなるかもしれません。さらにひょっとしたら、中学や
高校の授業でとりあげられるかもしれません。
今すぐの影響は
100年たっても生き残る言語 (スコア:3, 興味深い)
30年どころか、100年たっても間違いなく生き残るであろう言語が少なくとも2つはあるでしょう。アセンブラとCです。
これらの言語の特異な点は、言語のsemanticsに面倒な実行時の支援処理や初期化が一切含まれていないことです。すなわち、自分で作ったエントリポイントにいきなり処理を飛ばしてもきちんと動作するわけです。これは計算機をbootさせるためには
Re:100年たっても生き残る言語 (スコア:2, 興味深い)
アセンブラについては CPU が存在している限り消えないでしょうが、
C言語に関してはスレッドもサポートしていない言語が
30年、100年後に生き残っているとは思えません。
もし、残っているとしても、今の COBOL 並みの地位にいると思い
by rti.
Re:100年たっても生き残る言語 (スコア:5, すばらしい洞察)
Cが今まで生き延びてきた、そしてこれからも生き延びていけるであろう本質は、後から追加が必要になった機能を全てlibraryに押し込めることができるためです。決して新しい機能のために言語の文法や意味論に手を加え、それゆえに過去のsourceを捨ててしまうようなことをしなかったのが強く効いています。その点では、threadingなんか1996年にとっくに実現されているのです。しかも、それ以前に作られたsourceを一切壊さずに。
似たようなところでは、memory allocatorがあります。Cには汎用的なmemory allocatorとしての意味を持つ要素は一切あ
Re:100年たっても生き残る言語 (スコア:1)
残念ですが全てではありません。
上(?)で書いたように、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++が例として不適切だっただけでは?
Re:100年たっても生き残る言語 (スコア:1)
制御構造がないのはプロセッサとして失格、マル。
あなたは恐ろしい人ですね、そのallocatorが実はOS全体で使うallocatorになってしまうことに気が付かないとは。
OSの中でallocateする必要があるmemoryの大きさは、数十バイトから数GBまで非常に大きなばらつきを持っています。malloc(3)のように空のmemoryを持ってくるallocatorが実用になるのはせいぜい数十KBだけで、それ以上になると空きページを圧迫して性能を落としかねません。また、MB級になると全てを使い切らず、sparseにたたいていくことも増えてきます。
そういう需要の方が実は性能に大きく響くことが分かっているから、複雑な機能を持つVMをいろいろ作ったわけです。仕様は後から変えると困る人が増えるだけに、単純にnewとdeleteで片付けているとひどい目に遭いますよ。
Re:100年たっても生き残る言語 (スコア:0)
#この議論だと割とG7、まともだと思うが
Re:100年たっても生き残る言語 (スコア:0)
# ざっくりとしか追ってないのでAC
Re:100年たっても生き残る言語 (スコア:1)
若輩者な俺ですが敢えて言わせて頂くならば、
「言語作ってみたことがあれば判りますよ。
それも、Cとかみたいな有り触れた(ってのも変だが)言語とはあまり似てない言語を、ね。」
です。
勿論、洞察力のあるかたでしたら、わざわざ作るまでもなく理解可能かとも思います。
つまり俺は作ってしまったわけですが(笑)。
言語仕様ですか?
それは、(現在の計算機で可能な)任意のかたちに「定義」可能です:-D。
それとも、「関数という仕組み自体を自作」するような言語が
現在の計算機で実現不可能だ、とでも思ってらっしゃる?
よければLinkを書いておいた"PracticalScheme"頁を読んでおいてください。
まぁあっちは俺も先日やっと知り始めた分野なんで受け売り100%ですが、
逆にいえばそれだけ俺という劣悪フィルタを経由してません(ぷ
>Cにスレッドが導入されたからって、スレッド使わないソースはそのままで問題ないだろ。
あ。そうか。「使わない」部分の話だったのか。そう読めませんでした(^^;。
>C#がJavaの出来損ないである
それは嘘でしょう。出来損ない度でいえばJavaもC#も似たようなもんです。
C#が流行り損なう可能性は否定しませんけど(笑)。
Re:100年たっても生き残る言語 (スコア:1)
#プロセッサってなんですか?
「ない」とは言ってませんけど。
作ればいいしょ?と言っているのであって。
#まぁ、毎回自作する事には意味は無いでしょうけど。
>あなたは恐ろしい人ですね、そのallocatorが実はOS全体で使うallocatorになってしまうことに気が付かないとは。
あれ?そういえば、C++のnewって、複数用意して使い分けることが出来るんじゃなかったっけ?
#蛇足だがDelphiではNewInstanceというClassメソッド「を」多態することで同じことを実現できる。
#蛇足2。Delphiは、メーカの言葉を信じるならば、Delphi自身と「アセンブラと」で作られてるそうな。C無し。
##Delphiを作るためにはCのStackFrame制限を回避する必要が有るそうなので、Cじゃ実際困るのでしょうね。