R>Фактически это отказ от использования принципа раздельной компиляции. То есть, на выходе препроцессора каждый раз будет образовываться мегамонстр, который будет постоянно расти во времени и в один прекрасный момент просто не поместится в оперативной памяти. О каком ускорении компиляции может идти речь при этом?

Да, принцип раздельной компиляции делает код менее оптимизированным.
Препроцессор для #include <windows.h> добавляет 2Мб, мой самый большой проект около 2,5мб кода. Поэтому вряд ли я упрусь, когда он не поместится в оперативной памяти.
А если упрусь разобью проект на 2 или 3 cpp — разделю файлы по малозависимым группам.


R>P.S. А что с юнит-тестами? Где будут находиться юнит-тесты? Если в одном котле с продакшн-кодом, то все проблемы еще больше усугубляются. Если отдельно, тогда снова вернулись к раздельной компиляции и использованию заголовочных файлов.
Юнит-тесты у меня в отдельном файле, раздельной компиляции не требует, так как включается после.

R>P.P.S. Еще предвижу веселуху с порядком включения. Рано или позно окажется, что в модуле А нужно исбользовать что-то из модуля B, но поменять их местами нельзя, потому что модуль B зависит по порядку включения от модуля C. Конечно же, очевидным решением будет использование предварительного объявления. А когда количество одинаковых предварительных объявлений начнет зашкаливать за пределы здравого смысла будет принято решение о создании специальных файлов, в которые разработчики обязаны будут выносить все объявления. Закончится все адом.

Да, это мне тоже не нравиться. Ещё есть мысль сделать свой парсер или препроцессор, который будет 1 файл, разбивать на два cpp+h, что-бы проблем с зависимостью не было.
Но тут важно это сделать так что-бы при ошибки компилятор выдавал название и строку из оригинального файла, а не из созданного парсером.

R>Фактически это отказ от использования принципа раздельной компиляции. То есть, на выходе препроцессора каждый раз будет образовываться мегамонстр, который будет постоянно расти во времени и в один прекрасный момент просто не поместится в оперативной памяти. О каком ускорении компиляции может идти речь при этом?

Да, принцип раздельной компиляции делает код менее оптимизированным.
Препроцессор для #include <windows.h> добавляет 2Мб, мой самый большой проект около 2,5мб кода. Поэтому вряд ли я упрусь, когда он не поместится в оперативной памяти.
А если упрусь разобью проект на 2 или 3 cpp — разделю файлы по малозависимым группам.


R>P.S. А что с юнит-тестами? Где будут находиться юнит-тесты? Если в одном котле с продакшн-кодом, то все проблемы еще больше усугубляются. Если отдельно, тогда снова вернулись к раздельной компиляции и использованию заголовочных файлов.
Юнит-тесты у меня в отдельном файле, раздельной компиляции не требует, так как включается после.

R>P.P.S. Еще предвижу веселуху с порядком включения. Рано или позно окажется, что в модуле А нужно исбользовать что-то из модуля B, но поменять их местами нельзя, потому что модуль B зависит по порядку включения от модуля C. Конечно же, очевидным решением будет использование предварительного объявления. А когда количество одинаковых предварительных объявлений начнет зашкаливать за пределы здравого смысла будет принято решение о создании специальных файлов, в которые разработчики обязаны будут выносить все объявления. Закончится все адом.

Да, это мне тоже не нравиться. Ещё есть мысль сделать свой парсер или препроцессор, который будет 1 файл, разбивать на два cpp+h, что-бы проблем с зависимостью не было.
Но тут важно это сделать так что-бы при ошибки компилятор выдавал название и строку из оригинального файла, а не из созданного парсером.
Я удивлён почему до сих пор такого нет, или может есть ?