Каковы плюсы и минусы предварительно скомпилированных заголовков, особенно в среде GNU/Linux/цепочке инструментов?

предварительно скомпилированные заголовки кажутся, что они могут сэкономить много времени в больших проектах, но также кажутся занозой в заднице, у которых есть некоторые gotchas.

каковы плюсы и минусы использования предварительно скомпилированных заголовков, и особенно в том, что касается их использования в среде Gnu/gcc/Linux?

6 ответов


единственная потенциальная выгода для предварительно скомпилированных заголовков заключается в том, что если ваши сборки слишком медленные, предварительно скомпилированные заголовки могут ускорить их. Потенциальные минусы:

  • больше зависимостей Makefile, чтобы получить право; если они ошибочны, вы быстро создаете неправильную вещь. Не хороший.

  • в принципе, не каждый заголовок может быть перекомпилированы. (Подумайте о том, чтобы поставить некоторые #define перед #include.) Итак, в каких случаях gcc действительно прав? Сколько ты хочешь? доверять этой функции bleeding edge.

если ваши сборки достаточно быстры, нет причин использовать предварительно скомпилированные заголовки. Если ваши сборки слишком медленные, я бы рассмотрел

  • покупка более быстрого оборудования, которое дешево по сравнению с зарплатами

  • использование такого инструмента, как AT&T nmake или как класс ccache (Дирк прав), оба из которых используют надежные методы, чтобы избежать перекомпиляции.


Я не могу говорить с GNU/gcc / linux, но я имел дело с предварительно скомпилированными заголовками в vs2005:

плюсы:

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

плюсы:

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

на класс ccache кэширование интерфейса в gcc, g++, gfortran,... отлично работает для меня. Как говорится на его сайте

ccache-это кэш компилятора. Он действует как предварительный процессор кэширования на C / C++ компиляторы, использующие компилятор-E переключатель и хэш для обнаружения компиляция может быть удовлетворена от кэш. Это часто приводит к 5 до 10 время ускорения в общих сборниках.

в Debian / Ubuntu просто сделайте'apt-get install ccache' и создать софт-линки в, скажем,/usr/local/bin с именами gcc, g++, gfortran, c++, ... ссылки для /usr/bin/ccache.

[редактировать] чтобы сделать это более явным в ответ на некоторые комментарии: это по сути предоставляет предварительно скомпилированные заголовки и источник путем кэширования большего куска шага компиляции. Поэтому он использует идею, похожую на предварительно скомпилированные заголовки, и переносит ее дальше. Ускорение может быть драматичным-фактор от 5 до 10, как веб-сайт говорит.


для простого C я бы избегал предварительно скомпилированных заголовков. Как вы говорите, они потенциально могут вызвать проблемы, а время предварительной обработки действительно мало по сравнению с обычной компиляцией.

для C++ предварительно скомпилированные заголовки потенциально могут сэкономить много времени, поскольку заголовки c++ часто содержат большой код шаблона, компиляция которого является дорогостоящей. У меня нет практического опыта с ними, поэтому я рекомендую вам измерить, сколько экономии в компиляции вы получаете в своем проекте. Так, компиляция весь проект с предварительно скомпилированными заголовками один раз, затем удалите один объектный файл и измерьте, сколько времени потребуется для перекомпиляции этого файла.


документация GNU gcc обсуждаются возможные подводные камни с предварительно скомпилированные заголовки.


Я использую PCH в проекте Qt, который использует cmake в качестве системы сборки, и это экономит много времени. Я схватил несколько сценариев PCH cmake, которые нуждались в некоторой настройке, так как они были довольно старыми, но в целом было легче настроить, чем я ожидал. Я должен добавить, что я не большой эксперт cmake.

теперь я включаю большую часть Qt (QtCore, QtGui, QtOpenGL) и несколько стабильных заголовков сразу.

плюсы:

  • для классов Qt нет прямых объявлений необходимы, и конечно нет включает.
  • быстро.
  • простота установки.

плюсы:

  • вы не можете включить PCH include в заголовки. Это не большая проблема, за исключением того, что вы используете Qt и позволяете системе сборки переводить файлы moc отдельно, что является именно моей конфигурацией. В этом случае вам нужно #включить заголовки qt в заголовки, потому что MOC генерируются из заголовков. Решение было поставить дополнительные включают охранники вокруг #include в заголовке.