アカウント名:
パスワード:
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方面で聞いた話だったような気がします(雑誌の立ち読み(笑)で
目の端に触れた程度の「知識」でしかなくあやふやですみません)が、
ええとなんだったかな…たしかWindowシステムが導入されたときの話だったと思ったけど、
従来の各種のC言語処理系およびライブラリと、新しいGUIライブラリとでは、
2byte整数の引数を渡すとき、それを2byteのままStackに積むか、4byteに拡張してから積むか、
という流儀の違いが(なんでだか俺は知らないが)生じ、Stackを「積みなおす」ラッパー
(Cじゃ書けないですよねえ)が介在する必要が有った、なんていう話があったように記憶しています。
まあ、ライブラリのほうを作り直しやがれ、と怒られるような気もしないでもないですが、
少なくともこれは、アセンブラとかに片足突っ込むような「低級」面における
Cのゲンカイを示す1例かなんかに、なっているような気がするんですが、どうでしょうか?
高級方面だけにStack云々の問題が有るわけではなく、それどころかむしろ低級方面にその問題は多いんじゃないかと
俺は邪推します。少なくとも高級方面では、富豪的に「そんなもん同じにしとけ。面倒だからよ。」
で済ませてしまってもバレない(^^;ことのほうが多いんじゃないかなあ?
それとも、アセンブラレベルにおいても、Stackの使い方の違いというものは、
「気にするに値しないほど些細な」問題にしか見えない問題であるのでしょうか?
Re:100年たっても生き残る言語 (スコア:1)
>という流儀の違いが(なんでだか俺は知らないが)生じ、Stackを「積みなおす」ラッパー
>(Cじゃ書けないですよねえ)が介在する必要が有った、なんていう話があったように記憶しています。
こいつは「int型のサイズは規定なし、システムに都合がいいように決める」という仕様から派生する問題です。
問題であることには違いは無いですが、
>>hardware architectureとの親和性、assemblerとの親和性の高さ
を優先した結果であって、単純に「欠陥」といえるものではありません。
>少なくとも高級方面では、富豪的に「そんなもん同じにしとけ。面倒だからよ。」
>で済ませてしまってもバレない(^^;
「hardware architectureとの親和性」といってる時点で高級方面の話じゃないですよね。
少なくとも高級方面だけを考えればいいなら、Cよりもいいものはいくらでもありますよ。
Cを使う必然性はまるでないと言ってもいいかもしれない。
>それとも、アセンブラレベルにおいても、Stackの使い方の違いというものは、
>「気にするに値しないほど些細な」問題にしか見えない問題であるのでしょうか?
8bitから64bitまで、Stackが数KB程度の組み込み用途からサーバまでといった守備範囲の広さがCの強みでしょう。
かなり手を加える必要がある場合も多いですが、あるは程度のソースの流用が効きます。
Cというのは「Stcakに何byte積むか」といった面での互換性問題よりも「限られたりソースを効率よく利用できる」ことを優先することでアセンブラに比べれば高い移植性と互換性を幅広くサポートしようとする方向性を持っているので、富豪的アプローチを前提としている処理系と同じ土俵で比べることには無理があります。
100年後も生き残っているかはかなり疑問ですが、(アセンブラは別として)Cと同じような守備範囲で他に代替できるプログラム言語が登場しない限りCは生き残っていくでしょう。
うじゃうじゃ
Re:100年たっても生き残る言語 (スコア:1)
どこら辺が満たしてないんでしょうか。
新旧2つの処理系の間に違いがあるといわれても、、、だから?としか。
別にCに限った話でも何でもないような。
ライブラリを新しい処理系でrebuildすれば済みそうにも聞こえますし。
低水準で.b/.w/.dwのstack sizeが重要なのは当然ですね。
把握してなければ簡単に暴走するんですから。
高級言語なら、内部は全部Veriantなんてことしたってかまわんでしょう。
でも、それはStackFrameの使われ方とは別の話ではないですか?
この程度の内容に落ち着くんでは、Schemeの話は意味が無くなってしまいます。
結局、C言語のStackFrameではどんなことをしようとしたときに効率が悪いのか?
という疑問には答えてもらえないんでしょうか?
-//-