Эффективный C ++ «35. Минимизировать зависимости компиляции между файлами». Это все еще актуально сегодня?

Question

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

Мои вопросы:

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

• Где я могу найти больше примеров использования этой техники? (например, Gnome или другие проекты OSS)

P.S. Я использую 2-е издание.

Answer 1

Сокращение времени компиляции - красная сельдь и форма преждевременной оптимизации. Реорганизация вашего кода для сокращения времени компиляции (когда это имеет значение) можно сделать , но с некоторыми большими затратами.

Что касается Gnome, у Gnome есть «закрытый указатель» в каждом GObject. Это реализует идиому pimpl. Это уменьшает зависимости между исходными файлами и допускает некоторую форму инкапсуляции. Для проектов на Си меньше проблем с компиляцией.

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

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

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

Answer 2

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

Сказав это, можно переусердствовать - превратить все классы в PIMPL, объявить все вперед и т. Д. Выполнение этого просто приводит к запутанному коду, и его следует по возможности избегать.