私は、Ada が開発された時代には GC が普及していなかったことを知っています。また、組み込みプログラミングの主なユースケースでは、GC はまだ良い選択ではありません。
しかし、Ada が汎用プログラミング言語であることを考えると、言語とコンパイラの実装の後のリビジョンで導入された部分的でオプションの (明示的にタグ付けされたメモリ オブジェクトのみをトレースする) ガベージ コレクターではなかったのはなぜですか。
もはやガベージ コレクターなしで通常のデスクトップ アプリケーションを開発することは考えられません。
Ada は、軍事用途を念頭に置いて設計されました。その設計における大きな優先事項の 1 つは、決定論でした。つまり、Ada プログラムが、どの環境でも、すべてのオペレーティング システムの下で、毎回まったく同じように一貫して動作することを望んでいました。
ガベージ コレクターは、1 つのアプリケーションを 2 つのアプリケーションに変え、相互に作用します。Java プログラムは、GC が動作を開始することを決定したときにランダムな間隔でしゃっくりを発生させます。GC が遅すぎると、アプリケーションがヒープを使い果たしてしまう可能性があります。
簡素化: ガベージ コレクターは、設計者が望んでいないプログラムに可変性をもたらします。あなたは混乱を引き起こします-あなたはそれを片付けます！毎回同じコード、同じ動作。
エイダが猛烈な世界的成功を収めたわけではありません。
Ada は武器をリアルタイムで制御する防衛システムで使用するために設計されており、ガベージ コレクションがアプリケーションのタイミングに干渉するためです。これは危険であるため、Java には、医療や軍事制御システムには使用しないという警告が何年もの間表示されてきました。
Java でそのような免責事項がなくなった理由は、基盤となるハードウェアがはるかに高速になったことと、Java の GC アルゴリズムが改善され、GC の制御が改善されたためだと思います。
Ada が 1970 年代と 1980 年代に開発されたのは、コンピューターが現在よりもはるかに強力でなく、制御アプリケーションではタイミングの問題が最も重要であった時代です。
まず、この言語にはガベージ コレクションを禁止するものは何もありません。
次に、一部の実装ではガベージ コレクションが実行されます。特に、JVM ガベージ コレクトを対象とするすべての実装。
第 3 に、すべてのコンパイラである程度のガベージ コレクションを取得する方法があります。アクセスタイプが範囲外になったときに、そのオブジェクトの格納用に一定量のスペースを確保するように言語に具体的に指示した場合、そのスペースはその時点で破棄されます。私は過去にこれを使用して、ガベージコレクションを少し取得しました。使用する宣言 voodo は次のとおりです。
type Foo is access Blah;
for Foo'storage_size use 100_000_000; --// 100K
これを行うと、Foo ポインターが指す Blah オブジェクトに割り当てられたすべて (100K) のメモリは、Foo 型がスコープ外になるとクリーンアップされます。Ada ではサブルーチンを他のサブルーチン内にネストできるため、これは特に強力です。
storage_size とストレージ プールでできることの詳細については、LRM 13.11を参照してください。
第 4 に、適切に作成された Ada プログラムは、C プログラムほど動的メモリ割り当てに依存する傾向がありません。Cには、実践者がポインターを使用してペイントすることを学んだ多くの設計上の穴がありました. これらのイディオムの多くは、Ada では必要ありません。
Free() プロシージャを実装する方法の非常に簡単な例を共有したいと思いました (これは、すべての C プログラマーになじみのある方法で使用されます)...
with Ada.Integer_Text_IO, Ada.Unchecked_Deallocation;
use Ada.Integer_Text_IO;
procedure Leak is
type Int_Ptr is access Integer;
procedure Free is new Ada.Unchecked_Deallocation (Integer, Int_Ptr);
Ptr : Int_Ptr := null;
begin
Ptr := new Integer'(123);
Free (Ptr);
end Leak;
プログラムの最後に Free を呼び出すと、割り当てられた整数がストレージ プール (C 用語では「ヒープ」) に返されます。valgrind を使用して、これにより実際に 4 バイトのメモリ リークが防止されることを実証できます。
Ada.Unchecked_Deallocation (一般的に定義されたプロシージャ) は、「new」キーワードを使用して割り当てられる可能性のある任意の型で使用できます (私が思うに)。詳細については、Ada リファレンス マニュアル (「13.11.2 Unchecked Storage Deallocation」) を参照してください。
まず、最近誰が Ada を使っているか知りたいです。私は実際にこの言語が好きで、Linux/Ada 用の GUI ライブラリさえありますが、アクティブな Ada 開発については何年も聞いていません。その軍事的つながりのおかげで、それが古代の歴史なのか、それとも大成功を収めたためにその使用に関するすべての言及が機密扱いになっているのか、私には本当にわかりません.
Ada に GC がないのにはいくつかの理由があると思います。何よりもまず、ほとんどのコンパイル済み言語が主にスタックまたは静的メモリ、またはいくつかのケースでは明示的なヒープの割り当て/解放を使用していた時代にさかのぼります。一般的な哲学としての GC が実際に始まったのは 1990 年頃で、OOP、改善されたメモリ管理アルゴリズム、およびすべてを実行するためのサイクルを節約するのに十分強力なプロセッサが独自のものになったときです。1989 年に Ada を単にコンパイルして IBM 4331 メインフレームにできることは、まったく無慈悲でした。今、私はそのマシンの CPU を凌駕できる携帯電話を手に入れました。
もう 1 つの正当な理由は、厳密なプログラム設計にはメモリ リソースの正確な制御が含まれ、動的に取得されたオブジェクトをフロートさせることは許容されるべきではないと考える人がいるからです。悲しいことに、動的メモリがますます一般的になるにつれて、非常に多くの人がメモリ リークを起こすようになりました。さらに、高水準言語に対するアセンブリ言語の「効率」や、ORM システムに対する生の JDBC の「効率」と同様に、手動メモリ管理の「効率」は、スケールアップするにつれて反転する傾向があります (ORM ベンチマークを見たことがあります)。同等の JDBC は半分しか効率的ではありませんでした)。直感に反することは承知していますが、最近のシステムは、大規模なアプリケーションをグローバルに最適化するのにはるかに優れており、表面的に小さな変更に対応して根本的な再最適化を行うことができます.
残念ながら、リアルタイム システムでは GC メモリを使用できないと言う人たちとは意見を異にする必要があります。GC は、数分ごとにシステム全体をフリーズさせるものではなくなりました。最近では、メモリを再利用するためのはるかにインテリジェントな方法があります。
あなたの質問は間違っています。します。GC を処理する ada.finalization パッケージを参照してください。