アカウント名:
パスワード:
C#に置き換わり、C++は廃れてしまったりするのでしょうか
そんなことないと信じています。 というか、C#ってC++
30年どころか、100年たっても間違いなく生き残るであろう言語が少なくとも2つはあるでしょう。アセンブラとCです。
これらの言語の特異な点は、言語のsemanticsに面倒な実行時の支援処理や初期化が一切含まれていないことです。すなわち、自分で作ったエントリポイントにいきなり処理を飛ばしてもきちんと動作するわけです。これは計算機をbootさせるためには
プログラムは全てユーザプロセスとして動くものばかりではありませんよ。あるOSの元でプログラムが動くと勝手に仮定すると、Cの重要な本質を見失ってしまいます。
一般的なコンパイラ出力の C 処理系のみを考えても、スタートアップコードを必要とします。これは C 以外のもので書かれていますよね。
私はとあるRISCの評価中、IPLのためのload addressとentry addressだけをheaderとしてつけたC言語のプログラムを組んだことがあります。cross compilerゆえlibraryどころかstartupすら使えませんでし
brake-handle さんの書いたコードが実行される前に、フレームポインタやスタックポインタをセットする(スタートアップの代わりを果たす)コードがあったはずですが、、、
stack pointerの更新にinline assemblerを使えば、残りの部分はCで書くことができます。特にmemory mapped I/Oの場合はそうです。この場合、ROMにCで作ったcodeを焼き、Cの関数をCPUの初期program counterに合わせることすら可能になります。
実用上の問題ない話ですが、C では書けないプログラムがあります。メモリアドレス番値 0 に対するメモリアクセスです。
Cが今まで生き延びてきた、そしてこれからも生き延びていけるであろう本質 は、後から追加が必要になった機能を全てlibraryに押し込めることができるた めです。決して新しい機能のために言語の文法や意味論に手を加え、それゆ えに過去のsourceを捨ててしまうようなことをしなかったのが強く効いています。
inline
全体に対する感想なぞありません。VBで生成したcodeをUnixの元で走らせることに成功したのですか? 現実にやっていないことを話してもらっては困ります。
強いて挙げるとすれば、あなたはOSの束縛から逃れることができていないのでしょう。だから私が一切持ち出していないにもかかわらずあなたはOSのABIの話をしたのです。この時点で残りを読む気が全て失せました。
私はとあるRISCの評価中、IPLのためのload addressとentry addressだけをheaderとしてつけたC言語のプログラムを組んだことがあります。cross compilerゆえlibraryどころかstartupすら使えませんでした。それでもmain()をいきなりentry addressとしてきちんと動作しているんです。
より多くのコメントがこの議論にあるかもしれませんが、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年たっても生き残る言語 (スコア:2, 参考になる)
言語の semantics を考えるときは、その言語の色々な実装(例えば C言語だったら
C インタプリタ)でその話が成り立つかどうかを考えるべきです。
> これらの言語の特異な点は、言語のsemanticsに面倒な実行時の支援処理や初期化が
> 一切含まれていないことです。すなわち、自分で作ったエントリポイントにいきなり
> 処理を飛ばしてもきちんと動作するわけです。これは計算機をbootさせるためには必
> ず通らなければならない関門であり、ほかの言語にはマネができません。どんなにプ
> ログラムが組
コンタミは発見の母
Re:100年たっても生き残る言語 (スコア:1)
プログラムは全てユーザプロセスとして動くものばかりではありませんよ。あるOSの元でプログラムが動くと勝手に仮定すると、Cの重要な本質を見失ってしまいます。
私はとあるRISCの評価中、IPLのためのload addressとentry addressだけをheaderとしてつけたC言語のプログラムを組んだことがあります。cross compilerゆえlibraryどころかstartupすら使えませんでし
Re:100年たっても生き残る言語 (スコア:1)
> c言語のプログラムを組んだことがあります。cross compilerゆえlibraryどころかstartupすら
> 使えませんでした。それでもmain()をいきなりentry addressとしてきちんと動作しているんです。
> なので、上述の命題は誤りです。
brake-handle さんの書いたコードが実行される前に、フレームポインタやスタックポインタを
セットする(スタートアップの代わりを果たす)コードがあったはずですが、、、
> osの設計を変えてもcできちんと動作するプログラムが存在
コンタミは発見の母
Re:100年たっても生き残る言語 (スコア:1)
stack pointerの更新にinline assemblerを使えば、残りの部分はCで書くことができます。特にmemory mapped I/Oの場合はそうです。この場合、ROMにCで作ったcodeを焼き、Cの関数をCPUの初期program counterに合わせることすら可能になります。
雑感なり感想が欲しいナリ (スコア:1)
> Cで書くことができます。... 合わせることすら可能になります。
brake-handle の旦那。そりゃもう反則ですだ。
2つ親のコメントでは移植性の話をしていたし、 この コメント [srad.jp] では、せっかくいいこと書いていたのに
inline
コンタミは発見の母
手元で実現してない話をしないように (スコア:1)
全体に対する感想なぞありません。VBで生成したcodeをUnixの元で走らせることに成功したのですか? 現実にやっていないことを話してもらっては困ります。
強いて挙げるとすれば、あなたはOSの束縛から逃れることができていないのでしょう。だから私が一切持ち出していないにもかかわらずあなたはOSのABIの話をしたのです。この時点で残りを読む気が全て失せました。
Re:手元で実現してない話をしないように (スコア:0)
Re:手元で実現してない話をしないように (スコア:1)
> だから私が一切持ち出していないにもかかわらずあなたはOSのABIの話をしたのです。
> この時点で残りを読む気が全て失せました。
私は無論 OS の束縛から逃れていませんが、それを意識しております。
逆に私の目には brake-handle さんが、C 言語が ABI に依存している、つまり
OS やアーキテクチャに束縛されていることに無自覚なように見えます。 これも、C コンパイラが出力したオブジェクトコードがなぜきちんど動作するのかを考えると、
ABI の話が出てきますよね?
> 全体に対する感想なぞありません。VBで生成したcodeをUnixの元で走らせることに成功したの
> ですか? 現実にやっていないことを話してもらっては困ります。
本当に私のコメント [srad.jp]を読まずにレスをつけているのですね。
私のコメントは brake-handle さんのこの [srad.jp]コメントに対するものですよ。
コンタミは発見の母