アカウント名:
パスワード:
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 に対するメモリアクセスです。
0を使うのもあくまでlibraryの都合です。別に言語仕様がaccessを禁止しているわけではあり ません(DOSのころは割込ベクタを直接書き換えるために0番地をaccessしていた)。お望み なら、0xffffffffを使ったっていいんです。ただ、それだとaddress spaceの大きさによって値が 変わってしまうことや、一部のRISCではalignment errorを起こすために0を選んだのです。
この情報はどこで聞かれました? 歴史的経緯はおいておくと、 以下のことは言語仕様によって決まっています。
より多くのコメントがこの議論にあるかもしれませんが、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)
この情報はどこで聞かれました?
歴史的経緯はおいておくと、 以下のことは言語仕様によって決まっています。
コンタミは発見の母
Re:ナルポインタ (スコア:1)
正確には"無効であることが保証される値"です。内部的には処理系依存。
CPU 0番地が有効な処理系では、内部で違う値を振らなくてはなりません。
別に有効な値でも、処理系が"そこは無効"とする値でもかまいません。
MS-Cはデータセグメントの先頭にNULLを割り当てていましたね。
組み込み系では専用のコンパイラが使われることが多いですが、ANSI標準なんて
ことはまずありません。最初から、NULLに無効な値を定義することだってあります。
-//-
Re:ナルポインタ (スコア:1)
> 別に有効な値でも、処理系が"そこは無効"とする値でもかまいません。
> MS-Cはデータセグメントの先頭にNULLを割り当てていましたね
ですね。
ただ ソースコード上の `0' の表記と、ナルポインタの内部表現を変えた時に、
メモリの 0 番値にどうやってアクセスするかは頭をひねらないといけないと思います。
フラットなメモリ空間を持つシステムで実装を行なうなら、
pointer の内容がメモリアドレスから定数オフセット分ずれていると
するとオーバーヘッドが小さいかしら?
(ポインタの内容) = (メモリアドレス) - (仮想記憶のページサイズ; 例えば 4K)
としておいて、
int* p;
p = (int*)4096;
*p = 0 ; // メモリ 0 番への書き込み
p = 0;
*p = 0 ; // これはヌルポインタへのアクセス。
コンタミは発見の母