アカウント名:
パスワード:
実行時に静的リンク/ディスプレイが不要になるため、実行時環境の手抜きができるということでしょう。
実行時環境とは何の関係もありませーん。スタティックリンクを含めたアクティベーションレコードやディスプレイをセットアップするのはコンパイラのお仕事です(スタティックリンクを含めてアクティベーションレコードをきちんとセットするようなコードを生成する訳ですから)。つまり、Cはコン
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
コンピュータは旧約聖書の神に似ている、規則は多く、慈悲は無い -- Joseph Campbell
ソースコードの書き方にも問題がある. (スコア:4, 興味深い)
grubがコンパイラのバグという地雷を踏んだ理由の一つとして
そのソースコードの書き方にも原因があると思います.
grubの該当するソースコードは,関数の中で関数を定義するという妙な記述をしています.
これは,一般的なC言語の文法上はエラーになるので,めったに利用されない
Re:ソースコードの書き方にも問題がある. (スコア:1, 参考になる)
て、識別子の有効範囲規則はそのために存在していました。Pascal, PL/I, Ada ...
むしろ、C言語の仕様が手抜きではないでしょうか。手続きが入れ子にできなければ、
実行時に静的リンク/ディスプレイが不要になるため、実行時環境の手抜きができる
ということでしょう。
Think Pascalで、コールバック手続きを内部手続きにしておくと、大域変数を別途
宣言する必要がなくて、非常に便利だったのを覚えています。
Re:ソースコードの書き方にも問題がある. (スコア:3, 参考になる)
> 実行時に静的リンク/ディスプレイが不要になるため、実行時環境の手抜きができる
> ということでしょう。
手続きの入れ子がなくても、C の機能に限定しても、ソース分割で充分な気がします。
今日ではクラスによる分離、名前空間の方が有効だと思います。
実際に、分割コンパイルができる Turbo Pascal では、入れ子が深くなって
読みにくくなるのを避けるため、分割単位でのローカルな手続きを使っていました。
大域変数も、分割単位のスコープのローカル変数に閉じ込められました。
gcc の nest function は、GNU Pascal の副産物のように聞いていますが、
地雷には違いないようですね。
Re:ソースコードの書き方にも問題がある. (スコア:0)
実行時環境とは何の関係もありませーん。スタティックリンクを含めたアクティベーションレコードやディスプレイをセットアップするのはコンパイラのお仕事です(スタティックリンクを含めてアクティベーションレコードをきちんとセットするようなコードを生成する訳ですから)。つまり、Cはコン