FreeBASIC DevFbcMem

メモリ・アロケーションは、一般にかなり遅いので、fbc は、できるだけメモリ・アロケーションを回避しようとします。
list.bas の中に実装されたリンクリストは、組込みメモリ・プールに付属します。
したがって、ほとんど、すべてのリストはプールされます。
記憶プールは、大きな塊を事前に割り当てて、そして、多くの小さなノードを速く渡すことができます。
これらのリストは、実行ファイルで、リンクするライブラリのリストのような、単純なものに使用されます。また、ASTノードのような、より重いものにも使われます。
メモリ・プールは、事態を促進すると期待されます。 (しかし、これが確認されたことはありません。)

多くの場所で、コンパイラは、メモリ・アロケーションを避けるために、単純に、グローバル/静的変数（たとえば固定長文字列）を使います。
トークンは、良い例です：lex.bas は、トークンに入力文字を解析して、静的バッファに、トークン・テキストを保存します。
トークン・テキストは、以下の通りです：変数名、文字列直定数、その他。
しかし、すべてのトークンはここに保存されるので、プリプロセッサは、マクロを正しく記録することができます。
ここで、パーサーが対処しなければならないトークンの膨大な数を考慮してください：たとえば、FB の現在の Windows ヘッダは、〜100k トークンにもなります。
動的に、バッファをあらゆるトークンに割り当てると、直に非効率になります。

もちろん、トークンの長さは、静的バッファーを使うことで制限されます。しかし、fbc の 1024 バイトのデフォルトは誰にとっても十分であるべきです。
同様の長さ制限は、固定長バッファーを使うために、コンパイラー中の多くのものに当てはまります。
ほとんどの状況で、コンパイラー中のバッファーは、それらの完全な可能性を使われていません。つまり、バッファーは、それらがそうである必要があるより大きいです。

これらは、コンパイラが、動的メモリ・アロケーションを、まったく使わない、という意味ではありません。
アロケーションが、リスト/プールを使うより簡単で、速度が重要でない状況では、動的メモリ・アロケーションが使われます。
FB の組み込み文字列型も、多くの場所で使われます。
文字列を割り当てておくと、文字列は非常に効率的です。
プリプロセッサで、マクロ・パラメータを文字列化する拡張は、文字列のものに基づく strReplace() を使います。そして、それは速いです（十分に）。
その他に、動的な文字列（それは文字列のものと基本的に同じです）は、マクロ記録からマクロ拡大まで、プリプロセッサの至る所で使われます。

メモリ外の、状況/割付け失敗は、それほど深刻ではありません。
allocate() が呼ばれる、いくつかの場所に、NULL チェックがあります。しかし、fbc の残りが NULL をチェックしないので、これらのチェックは無意味です。
NULL は、時々、エラーを示すために使われます。例えば、astNew*() のような関数によってです。
さらに、コンパイラーは、すべてを deallocate() するとは限りませんが、OSに掃除を行わせます。