私はDを学ぶことを考えています（基本的に「C++は正しく行われ、ガベージコレクションとスレッド間のメッセージパッシングを備えています」）、長年のC++プログラマーである同僚と話しましたが、基本的に彼はガベージコレクター自体に深刻なタイミングの問題があると不平を言いましたソフトリアルタイムタイプのアプリケーションでも。
リアルタイムアプリを書く必要があるというわけではありませんが、たとえばデータベースの開発でGCがどれほど問題になるのでしょうか? （GCが統計的に課すと思われる追加のメモリ使用オーバーヘッドから抽出）
（DでGCをオフにできることはわかっていますが、それは車を取り除くことで車に関連する問題を取り除くことができると言っているようなものです-本当ですが、それは私が選択したい解決策ではありません）
これは本当ですか？そのような問題は実際にはどれほど深刻ですか？たとえば、DでGCを使用してデバイスドライバーを開発することは、実用的/賢明な/良い習慣ですか?
D には GC がありますが、すべてに GC を使用する必要はありません。D には構造体もあり、C++ のクラスと構造体 (ポリモーフィズムを除く) のように機能します。
最新のマネージ言語では、十分なメモリがある限り、GC は問題になりません。これは、C++ のようなアンマネージ言語にも当てはまります。ただし、C++ では、メモリ不足はそれ以上メモリを割り当てることができないことを意味し、Java ではメモリ不足は GC が起動するまでの遅延を意味します。
したがって、大量のオブジェクトを割り当てることを計画している場合は、はい - GC が問題になる可能性があります。しかし、おそらくそれほど多くのオブジェクトを割り当てる必要はありません。Java では、文字列、日付、座標などを格納するためにオブジェクトを使用する必要があります。これにより、実際にヒープがいっぱいになり、GC が呼び出される可能性があります (幸いなことに、最新の JVM は世代別 GC を使用してこれらのタイプのオブジェクトを最適化します)。D では、これらの目的に構造体を使用し、実際に GC が必要な場合にのみクラスを使用します。
経験則として、通常はできる限り構造体を使用したいと思うでしょうが、割り当て解除を処理したり、コピーと破壊を防止したりするために何か特別なことをしている場合は (D では非常に高速ですが)、その型をなくしたクラスにします。もう一度考えます。
私は個人的に、「十分なメモリがある限り、GC は問題にならない」という声明をあまり承認しません。つまり、基本的には、メモリを適切に処理する代わりに先に進んで無駄にし、メモリがなくなると、GC がすべてを収集するまで突然 1 秒待たなければならないことを意味します。
1 つには、それは本当に悪い GC の場合にのみ発生します。たとえば、c# の GC は、オブジェクトを非常に高速かつ頻繁に収集します。頻繁に使用される関数に割り当てても、コレクションを実行するためにメモリが不足するまで待機しなくても、問題は発生しません。
私は D2 GC (私たちは D1 を使用しています) の現在の機能について完全に最新のものではありませんが、当時の動作は、メモリのプールを割り当て、割り当てごとにその一部を提供するというものでした。90% が割り当てられ、さらに必要な場合は、コレクションを開始するか、システムからさらに割り当てます。（またはそのようなもの）。(D1 の場合) コレクションを早期に開始する同時 GC もありますが、それらをバックグラウンドで実行しますが、フォーク syscall を使用するため、Linux 専用です。
したがって、現在の D GC は、注意して使用しないと、小さいながらも目立つフリーズを引き起こす可能性があると思います。しかし、それを無効/有効にすることができます。たとえば、リアルタイムで重要なことを行うときは無効にし、コードのその重要な部分が終わったら再度有効にします。
データベースの場合、D GC はまだ準備ができていないと思います。私はメモリを大幅に再利用し、その種のアプリケーションでは GC にまったく依存しません。