1

私は、はるかに大きくなりそうな大規模なプロジェクトに取り組んでいます。それが起こる前に、私が取り組みたい問題の 1 つは、ビルド速度です。

以前は、単一のコンパイル ユニット / Unity ビルドを使用して、ビルド速度を大幅に改善していました。詳細はこちらhttp://buffered.io/posts/the-magic-of-unity-builds/

本質的に、複数の #include other.cpp を含む .cpp ファイルを 1 つ作成します。

例 scu.cpp の内容

#include apple.cpp
#include banana.cpp
#include cherry.cpp

.....

1 つの scu.obj を作成します。これにより、ファイル I/O が減少するため、ビルド速度が低下します。

しかし、デメリットもあります

  • .cpp のグローバル変数/関数は共有されており、競合する可能性があります
  • 開発者は、.cpp にファイルを #include するのを忘れて、それを回避することができます

もう 1 つの悪い点は、開発者が scu.cpp を手動で保守する必要がある可能性があることです (ただし、これは自動化されるため、問題にはなりません)。

これらの欠点のため、SCU から離れました。しかし、ビルド速度の改善が本当に魅力的であるため (50 ～ 75% の減少) 、私はそれを元に戻したいと思っています。

これらの競合を回避する方法はありますか? テストしました

scu.cpp の内容

namespace unique_1 {
#include apple.cpp
}
namespace unique_2 {
#include banana.cpp
}
namespace unique_3 {
#include cherry.cpp
}

しかし、それはエラーを生成するだけです

error C3083: 'vc_attributes': the symbol to the left of a '::' must be a type
........

これは、名前空間内に #include することに起因します。

代替手段はありますか？他の解決策はありますか？

このスレッドはいいえを提案します (残念ながら)

安全な Unity ビルド

非 SCU ソリューションをテストするための別のビルドは簡単に実行できます。しかし、私たちの組織内では眉をひそめています。すなわち

  • グローバル変数/関数は有効です (C++ テキスト ブックで)
  • 気付かないうちに SCU/非 SCU を壊す可能性があります (ビルドが壊れるまで)
4

0 に答える 0