Сокращает количество cpp единиц перевода хорошая идея?

Один существенный недостаток этого подхода вызван наличием одного файла .obj для каждой единицы перевода.

Если вы создаете статическую библиотеку для повторного использования в других проектах, вы часто будете сталкиваться с более крупными двоичными файлами в этих проектах, если у вас есть несколько огромных единиц перевода вместо множества маленьких, потому что компоновщик будет включать только файлы .obj, содержащие функции / переменные. действительно упоминается внутри проекта с использованием библиотеки.

В случае больших единиц перевода более вероятно, что имеется ссылка на каждую единицу и соответствующий файл .obj включен. В некоторых случаях большие двоичные файлы могут быть проблемой. Также возможно, что некоторые компоновщики достаточно умны, чтобы включать только необходимые функции / переменные, а не целые файлы .obj.

Также, если включен файл .obj и все глобальные переменные включены, то их конструкторы / деструкторы будут вызываться при запуске / остановке программы, что, безусловно, потребует времени.

Я видел, что вы делаете в видеоиграх, поскольку это помогает компилятору выполнять оптимизацию, которую он в противном случае не смог бы сделать, а также сэкономить много памяти. Я видел, как к этой идее относятся «убер-сборка» и «массовая сборка». И если это помогает ускорить сборку, почему бы и нет ..

Объединение большего числа файлов исходного кода C ++ в один файл - это подход, который в последнее время упоминался несколько раз, особенно когда люди создавали большие системы и загружали сложные файлы заголовков (которые тогда будет повышено).

Когда вы упомянули VS, я обнаружил, что количество включаемых файлов в проекте и особенно размер пути включения, похоже, влияют на время компиляции Visual C ++ гораздо больше, чем на время компиляции g ++ , Это особенно характерно для множества вложенных включаемых файлов (опять же, boost делает это), поскольку для поиска всех включаемых файлов, требуемых исходным кодом, требуется большое количество поисков файлов. Объединение кода в один исходный файл означает, что компилятор может быть намного умнее при поиске указанных включений, к тому же их явно меньше, так как можно было бы ожидать, что файлы в одном подпроекте, вероятно, будут включать очень похожий набор файлов заголовков.

Подход «много единиц компиляции» к разработке на C ++ обычно применяется из-за желания разделить классы и минимизировать зависимости между классами, чтобы компилятор перестраивал только минимальный набор файлов на случай, если вы внесете какие-либо изменения. Как правило, это хороший подход, но часто он неосуществим в подпроекте просто потому, что файлы в нем зависят друг от друга, так что вы все равно получите довольно большие перестроения.

подход к разработке на C ++ обычно исходит из желания отделить классы и минимизировать зависимости между классами, поэтому компилятору нужно только перестроить минимальный набор файлов, если вы внесете какие-либо изменения. Как правило, это хороший подход, но часто он неосуществим в подпроекте просто потому, что файлы в нем зависят друг от друга, так что вы все равно получите довольно большие перестроения.

подход к разработке на C ++ обычно исходит из желания отделить классы и минимизировать зависимости между классами, поэтому компилятору нужно только перестроить минимальный набор файлов, если вы внесете какие-либо изменения. Как правило, это хороший подход, но часто он неосуществим в подпроекте просто потому, что файлы в нем зависят друг от друга, так что вы все равно получите довольно большие перестроения.

Чем больше и меньше единиц трансляции, тем больше не используется преимущества параллельной компиляции. Я не знаю, какие компиляторы и какие платформы вы используете, но параллельная компиляция нескольких единиц трансляции может значительно сократить время сборки ...

Следуя посту Sharptooths, я бы хотел более подробно изучить полученные исполняемые файлы. Если они разные, я бы предпочел ограничить вашу технику отладкой сборок и прибегнуть к исходной конфигурации проекта для сборки основного выпуска. При проверке исполняемого файла я также смотрю на его объем памяти и использование ресурсов при запуске и во время работы.

Я не уверен, актуально ли это в вашем случае, но, возможно, вы можете использовать объявление вместо определения, чтобы уменьшить количество #include , которые вам нужно сделать . Кроме того, возможно, вы можете использовать идиому pimpl для той же цели. Мы надеемся, что это уменьшит количество исходных файлов, которые необходимо каждый раз перекомпилировать, и количество заголовков, которые необходимо вставить.

Я не думаю, что сокращение количества единиц компиляции - хорошая идея. Вы пытаетесь решить проблему с большим временем компиляции, и этот подход, кажется, помогает с этим, но вы получаете в дополнение:

1. Увеличенное время компиляции во время разработки. Обычно разработчик изменяет несколько файлов за раз, и компиляция, вероятно, будет быстрее для 3-4 небольших файлов, чем для одного очень большого файла.
2. Как вы упомянули, сложнее ориентироваться в коде, ИМХО, это чрезвычайно важно.

3. Вы может иметь место некоторая интерференция между файлами .cpp, включенными в один файл .cxx:

   a. Обычно в файле cpp (для отладочных сборок) определяется макрос new для проверки утечки памяти. К сожалению, это невозможно сделать до включения заголовков с использованием нового размещения (как это делают некоторые заголовки STL и BOOST)

   b. Обычной практикой является добавление объявлений using в файлы cpp. С вашим подходом это может привести к проблемам с заголовками, включенными позже

   c. Конфликты имен более вероятны

IMHO, гораздо более чистый (но, возможно, более дорогой способ) ускорить время компиляции - использовать некоторую распределенную систему сборки. Они особенно эффективны для чистых сборок.