アカウント名:
パスワード:
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を選んだのです。
この情報はどこで聞かれました? 歴史的経緯はおいておくと、 以下のことは言語仕様によって決まっています。
alloca、va_arg/va_start/va_end、setjmp/longjmp のように(ライブラリのみでは実装できないので)言語仕様に入れておいてくれよと言いたくなるような機能
意味がよく分かりません。libraryに欠けている機能は何ですか? 言語仕様に入れるべき理由は?
手元にあるFreeBSDのlibcは、allocaもsetjmp/longjmpも実装しています。libraryにしてはいけない理由は見当たりません。同様に、gccだってva_*をきちんと実装しています。
/* alloca_test.c */ /* Compile: gcc -S -O0 alloca_test.s #include <stdio.h> #include <alloca.h> void foo(){ char* p = (char*)alloca(100); }
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
私は悩みをリストアップし始めたが、そのあまりの長さにいやけがさし、何も考えないことにした。-- Robert C. Pike
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)
この情報はどこで聞かれました?
歴史的経緯はおいておくと、 以下のことは言語仕様によって決まっています。
コンタミは発見の母
見境なく言語仕様をごみ溜めにするべからず (スコア:1)
意味がよく分かりません。libraryに欠けている機能は何ですか? 言語仕様に入れるべき理由は?
手元にあるFreeBSDのlibcは、allocaもsetjmp/longjmpも実装しています。libraryにしてはいけない理由は見当たりません。同様に、gccだってva_*をきちんと実装しています。
Re:見境なく言語仕様をごみ溜めにするべからず (スコア:1)
また、多くの実装系では va_arg/va_start/va_end はコンパイラによって特殊に処理される擬似関数となっています。単なるライブラリとして書けないものをライブラリの振りをさせるのはまずいでしょう。
> 手元にあるFreeBSDのlibcは、allocaもsetjmp/longjmpも実装しています。
> libraryにしてはいけない理由は見当たりません。
alloca に絞って反論します。
FreeBSD はalloca 関数を本当に libc だけで処理していますか?
コンパイラ(gcc)で特殊な処理を入れていませんか?
少なくとも Linux(x86)上の gcc 2.95.3 では、alloca は擬似関数です。alloca 関数は alloca.h で宣言されたライブラリ関数のように見えますが、実体は違います。 出力されたアセンブラファイルからは外部関数の呼び出しが消え、esp レジスタの操作に変わっています。
私は、このようなコンパイラの支援を要求するものは、ライブラリ関数の範囲から逸脱していると考えています。
コンタミは発見の母