特定のコンパイル単位から「エクスポート」されるシンボルの数を減らすため、内部リンケージ (変数、フリー関数など) を使用する方がよいと読みました。そうすれば、ビルド時間が改善される可能性があります。
これは本当ですか?
内部リンケージを使用するもう 1 つの利点は、名前の競合の問題がないことです。
特定のコンパイル単位から「エクスポート」されるシンボルの数を減らすため、内部リンケージ (変数、フリー関数など) を使用する方がよいと読みました。そうすれば、ビルド時間が改善される可能性があります。
これは本当ですか?
内部リンケージを使用するもう 1 つの利点は、名前の競合の問題がないことです。
理論的にはそうですが... C++ はジェネリック プログラミングへと進化しました。また、名前空間の導入により、名前の競合の問題が制限されます。
すべてのオーケストレーションを処理し、最後の手段を提供する「マネージャー オブジェクト」をインスタンス化することを目的とする、メインのみを含む単一の cpp ファイルから階層的に含まれる「ヘッダーのみのライブラリ」の形式でプログラムを作成することが常により頻繁に行われます。最終的にエスケープされた例外をキャッチします。長いシンボル テーブルは、「プリコンパイル済みヘッダー」によって高速化できます。
この意味で、「エクスポート」するものがないため、すべてのリンケージは「内部」です。
より一般的には、外部リンケージが少ないとリンク時間が短縮され、内部リンケージが少ないとコンパイル時間が短縮されます。内部テーブルと外部テーブルのバランスが取れている場合に、最適な最小値が得られる可能性が最も高くなります。しかし、他にも注意すべき重要な要素がたくさんあります。
そのような本がまだ今日の標準にとって「良い」と見なすことができるかどうか疑問に思います.たとえば、イテレータについてそれが示唆していることは、今日の標準ライブラリが行うこと以外のすべてであることに気付きましたか?