Являются ли ненужные файлы включения накладными расходами?
Я видел пару вопросов о том, как обнаружить ненужные файлы #include в проекте C ++. Этот вопрос меня часто интересовал, но я так и не нашел удовлетворительного ответа.
Если есть несколько заголовочных файлов, которые не используются в проекте c ++, это накладные расходы? Я понимаю, что это означает, что перед компиляцией содержимое всех заголовочных файлов будет скопировано во включенные исходные файлы, и это приведет к большому количеству ненужной компиляции.
Как далеко распространяются такие издержки на скомпилированные объектные файлы и двоичные файлы?
Разве компиляторы не могут сделать некоторые оптимизации, чтобы убедиться, что это
вид накладных расходов не переносится в результирующие объектные файлы и
двоичные файлы?
Учитывая тот факт, что я, вероятно, ничего не знаю об оптимизации компилятора, я все же хочу спросить об этом, если есть ответ.
Как программист, который использует широкий спектр библиотек c ++ для своей работы,
какие методы программирования я должен следовать, чтобы избежать
такие накладные расходы? Познакомился ли я с каждым
библиотека работает единственный выход?
Решение
Это не влияет на производительность двоичного файла или даже содержимое двоичного файла почти для всех заголовков. Объявления вообще не генерировать код, определения inline / static / anonymous-namespace оптимизируются, если они не используются, и ни один заголовок не должен содержать видимых извне определений (это ломается, если заголовок включен более чем одним модулем перевода).
Как @ T.C. указывает на то, что исключением являются внутренне видимые статические объекты с нетривиальными конструкторами. iostream делает это, например. Программа должна вести себя так, как будто вызывается конструктор, а компилятору обычно не хватает информации для оптимизации конструктора.
Это, однако, влияет на то, сколько времени занимает компиляция и сколько файлов будет перекомпилировано при изменении заголовка. Для крупных проектов этого стимула достаточно, чтобы заботиться о ненужных включениях.
Другие решения
Помимо явно более длительного времени компиляции, могут быть и другие проблемы. Самый важный из них, IMHO, это зависимости от внешних библиотек. Вы не хотите, чтобы ваша программа зависела от большего количества библиотек, чем необходимо.
Затем вам также необходимо установить эти библиотеки в каждой системе, на которую вы хотите, чтобы программа строила. Это может стать кошмаром, особенно когда следующему программисту необходимо установить некоторую клиентскую библиотеку базы данных, хотя программа никогда не использует базу данных.
Кроме того, особенно библиотечные заголовки часто имеют тенденцию определять макросы. Иногда эти макросы имеют очень общие имена, которые могут нарушить ваш код или несовместимы с другими заголовками библиотек, которые вам могут понадобиться.
Конечно любой #include это накладные расходы. Компилятор должен проанализировать этот файл.
Так что избегайте их. Используйте предварительные декларации, где это возможно.
Это ускорит компиляцию. Смотрите книгу Скотта Майерса на эту тему.
Простой ответ — ДА, это накладные расходы в том, что касается компиляции, но для среды выполнения это просто создаст какую-то разницу. Причина, позволяющая сказать, что вы добавили #include <iostream> (только для примера) и предположим, что вы не используете ни одну из его функций, тогда g ++ 4.5.2 имеет дополнительные 18 560 строк кода для обработки (сборник). Но что касается времени выполнения, я вряд ли думаю, что это создает проблему с производительностью.
Вы также можете сослаться Неиспользуемые включения вредны в C / C ++? где мне очень понравилось это высказывание Дэвида Янга
Любые синглеты, объявленные как внешние в заголовке и определенные в
исходный файл будет включен в вашу программу. Это явно увеличивает
использование памяти и, возможно, способствует снижению производительности
вызывая один доступ к своему файлу страницы чаще (не большая часть
проблема в настоящее время, так как синглтоны обычно имеют размер от среднего до среднего и
потому что большинство людей, которых я знаю, имеют 6+ ГБ ОЗУ).
detector