アカウント名:
パスワード:
C#に置き換わり、C++は廃れてしまったりするのでしょうか
そんなことないと信じています。 というか、C#ってC++
30年どころか、100年たっても間違いなく生き残るであろう言語が少なくとも2つはあるでしょう。アセンブラとCです。
これらの言語の特異な点は、言語のsemanticsに面倒な実行時の支援処理や初期化が一切含まれていないことです。すなわち、自分で作ったエントリポイントにいきなり処理を飛ばしてもきちんと動作するわけです。これは計算機をbootさせるためには
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
人生の大半の問題はスルー力で解決する -- スルー力研究専門家
ISOってなんか意味あるの? (スコア:2, 興味深い)
よく分からないのですが、今のところ.NETフレームワーク以外に使用されるようなことはなさそうですし、標準でなくていいからMSのほうで勝手にやっていてくれという感じです。
ちなみに、
そんなことないと信じています。
というか、C#ってC++
// Give me chocolates!
Re:ISOってなんか意味あるの? (スコア:1)
ISOになると、各国政府がある程度の後押しをすることになってます。
例えば、おそらくJISにもなるでしょうし、情報処理技術者試験の
選択科目にもなるかもしれません。さらにひょっとしたら、中学や
高校の授業でとりあげられるかもしれません。
今すぐの影響は
100年たっても生き残る言語 (スコア:3, 興味深い)
30年どころか、100年たっても間違いなく生き残るであろう言語が少なくとも2つはあるでしょう。アセンブラとCです。
これらの言語の特異な点は、言語のsemanticsに面倒な実行時の支援処理や初期化が一切含まれていないことです。すなわち、自分で作ったエントリポイントにいきなり処理を飛ばしてもきちんと動作するわけです。これは計算機をbootさせるためには
Re:100年たっても生き残る言語 (スコア:1)
アセンブラは今風の延長のCPUがありつづける限り、その「後釜言語」が出現するってことを
考える意味が無いはずなので、そういう意味では未来永劫残るでしょう。
でもCは、後釜言語が出現するかも知れない。
30年後の俺らの後輩?は、今のCと似ているような似てないような後釜言語を
(そういう用途に)使っているかも知れない。
もちろんこれは、たまたま惰性でCが今のまま使われ続ける可能性を否定するものではありません。
ただ、残るにせよ残らないにせよ、それは「たまたま」であって、アセンブラのそれとは違って必然では無い、とは言えると思
Re:100年たっても生き残る言語 (スコア:1)
Cが生き残るのは「低機能で実装が簡単」だからで、機能が足らないから
廃れるってのは逆方向ではないですか?
リンク先読みましたが、組み込み系で多用されているZ80の発展型にガベコレを
実装した環境ってあるのでしょうか?Cに比べて実行時の要求リソースがかなり
大きいと思いますが。実装依存と書いてあるから、Cに匹敵する少リソースでの
実装形態もあるのかもしれませんが。
#Schemeは初めてかじったので、理解が浅い点はご容赦くださ
Re:100年たっても生き残る言語 (スコア:1)
(俺が)しようとしたわけじゃないですし、
恐れ多くもZ80様を忘れようと思っているわけでもありませんm(__)m
StackFrameの話ですが、StackFrameの1種類の使い方しか提供されなくて
変更不能(それを変更することはC自身の領分を超える)ということは、
都合(それこそ処理効率とか)に合わせて色々なStackFrameの使い方を
使い分けるということが出来ない、ということですよね。
ということは、もしそれが可能な(C似かも知れない)言語があったら、Cは
(組み込み用途でも)負ける、のではないか?とは思いました。
Closureだの継続
Re:100年たっても生き残る言語 (スコア:1)
わたしも玄人なんておこがましいこと言えるようなもんじゃないです。
そんなこと言ったら、本物の玄人が裸足で逃げだしてしまいます。
私にはStackFrameを使い分けるという概念がありません。
だから、どんなメリットがあるのかも理解できません。
よければ例を示していただけると。ポインタでもかまいませんので。
CPUがCに都合よくというのは歴史的には賛成できませんが
現実的に、基幹部がCで開発されることが主流である以上
あり得ない話ではないと思います。もっとも、基幹部のCに
高級アセンブラ以上の意味があるとは思えま
スタックフレームの使い分け (スコア:1)
C規約呼び出しの利点は caller が完全にフレームを制御するので、 可変長引数などが実現可能な点。複数の関数呼び出しが連続するとき フレームの解放をさぼれる点でしょう。
PASCAL規約呼び出しの利点の方は現在では認識し難たいですが、 以下のようなストーリーがあります。
RISC アーキにとってスタックレジ
コンタミは発見の母
Re:スタックフレームの使い分け (スコア:1)
以前どっかで聞いたような気がしますが、Pascal呼び出しだと、Stack後始末をするコードを持つ個所が、
「呼び出す側」じゃなく「呼び出される側」になることによって、その「数」が減る、という話だったような。
それ以外の例としては、やっぱり、Schemeの実装におけるスタックフレーム [dreamhost.com]あたりが参考になる、んでしょうか。
特に
>但し、現存するScheme処理系の多くはベースにC言語を用いており、このような特殊な スタック操作が実装しにくくなっています。
という辺りが、
Cと違うStackの使い方が欲しくなることが(こういう風に)有るのを物語っているんじゃないかと。
まあScheme(Lisp系)なので、「関数」という概念の定義自体がCのそれとは微妙に違う
(ルーチンおよびそれに直接従属する"状態"しか持たないCの関数に対し、
Lispの関数はルーチンに従属せずヨソからアクセスも可能な"状態"を持つことが出来るらしい。
つーかこれがClosureとかいう奴ことらしい。そういう考え方を導入するメリットについては
それこそそっちの頁とかを読んで下さい。俺もAuto変数とStatic変数だけじゃウンザリするのは十分経験済み)
ので、CのStackFrameとがらっと違うStackFrameが(効率を上げるために)要求されるのは、当然なんでしょうけどね。