Unity Builds in C : 速度向上かメンテナンスの悪夢か?

Unity ビルド: 利点と落とし穴

Visual Studio C では、単一の ALL をビルドする「すべてリリース」や「すべてデバッグ」などの構成を作成できます。 cpp ファイル。これには他のすべての .cpp ファイルが #include されます。このアプローチには顕著な利点がありますが、特定の課題もあります。

利点

• 迅速なコンパイルとリンク: Unity ビルドの大幅な削減コンパイラはファイルのみを処理するため、コンパイルとリンクに時間がかかります
• 並列コンパイル: Visual Studio はコードの複数の部分を並列でコンパイルできるため、ビルド速度がさらに向上します。

落とし穴

• メンテナンス問題点: 大きな ALL.cpp ファイルの管理は、特に変更やリファクタリングを行う場合に面倒になる可能性があります。
• 名前空間の公開: 匿名の名前空間は、個々の .cpp ファイルにプライベートではなくなりました。コンパイル単位全体にわたって変数と関数を可視化します。これにより、名前の競合やコードの混乱が生じる可能性があります。
• DLL の互換性: 匿名名前空間は、同じ DLL を使用する他のモジュールによって変更される可能性があるため、DLL 内のデータには適していません。ただし、匿名名前空間内の関数は受け入れられます。

追加の洞察

この実践は「Unity ビルド」として知られています。中央サーバーからのリリース ビルドなど、増分ビルドが必要ない環境で優れています。ただし、メンテナンスの問題により、通常は反復開発には適していません。

詳細については、以下を参照してください。リソース:

• https://buffered.io/posts/the-magic-of-unity-builds/
• http://randomascii.wordpress.com/2014/03 /22/make-vc-compiles-fast-through-Parallel-compilation/

以上がUnity Builds in C : 速度向上かメンテナンスの悪夢か?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。