アカウント名:
パスワード:
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に
高級アセンブラ以上の意味があるとは思えま
Re:100年たっても生き残る言語 (スコア:1)
> よければ例を示していただけると。ポインタでもかまいませんので。
下のほう(#186702)に書いたもので、お役に立ったでしょうか?
>CPUがCに都合よくというのは歴史的には賛成できませんが
でも、ほかの方の話だと、なんかあながち嘘でもないようですし(^^;;;。
#歴史的って何でしょう?CPUが設計され生産されればそれは全部「歴史」なので、実装が1つでも有れば条件を満たしますよね?
実際、CPUにありがち(って俺も多数のCPUを知っているわけじゃないですが)な命令だけど
Cでは直接呼べない命令、ってのは幾
Re:100年たっても生き残る言語 (スコア:1)
C言語が生まれた後のCPUに限って言えば、違う結論もあるということです。
"「命令数が十分だとは限らない」高級アセンブラ"には同意。
C言語の仕様範囲だけではローテイトもできなきゃOver/UnderFlowの検出もできない。
そういうことは _asm 使えと言うことで。
1命令実行して戻る関数なんてのは、今時のコンパイラはinline展開するし
そもそもマクロ定義にするのが妥当でしょう。
StackFrameの使い方で効率を上げられる。CはStackFrameの使い方が硬直化していて
効率を上げられないということですよね?問題は
Re:100年たっても生き残る言語 (スコア:1)
>効率を上げられないということですよね?問題は、どんな用途の効率なのかが明らかで
>ないことだと思います。
(略)
>hardware architectureとの親和性、assemblerとの親和性の高さは、開発「効率」を
>高めるために絶対必要な条件ですが、C言語はこの条件を満たしています。
そうでしょうか?条件満たしてますかね?
たしかX68000方面で聞いた話だったような気がします(雑誌の立ち読み(笑)で
目の端に触れた程度の「知識」でしかなくあやふやですみません)が、
ええ
Re:100年たっても生き残る言語 (スコア:1)
どこら辺が満たしてないんでしょうか。
新旧2つの処理系の間に違いがあるといわれても、、、だから?としか。
別にCに限った話でも何でもないような。
ライブラリを新しい処理系でrebuildすれば済みそうにも聞こえますし。
低水準で.b/.w/.dwのstack sizeが重要なのは当然ですね。
把握してなければ簡単に暴走するんですから。
高級言語なら、内部は全部Veriantなんてことしたってかまわんでしょう。
でも、それはStackFrameの使われ方とは別の話ではないですか?
この程度の内容に落ち着くんでは、Schemeの話は意味が無くなってしまいます。
結局、C言語のStackFrameではどんなことをしようとしたときに効率が悪いのか?
という疑問には答えてもらえないんでしょうか?
-//-