Как организовать заголовки STL?

Question

Я работаю над большим проектом, который использует STL, и у вас есть вопрос о вашем предпочтительном способе организации вашего STL #includes.

• Вы предпочитаете # включать каждый заголовок в исходный файл, который он использует. Например, если оба foo.cpp и bar.cpp требуют std::string, то оба они будут #include <string>.
• Вы предпочитаете иметь один файл заголовка, который включает все заголовки STL, которые использует ваш проект (т. Е. Добавить их в предварительно скомпилированный заголовок MS 'stdafx.h').

Преимущество первого метода состоит в том, что файл .cpp является самостоятельной единицей и может быть использован в другом проекте, не беспокоясь, что вам не хватает на #include. Преимущества второго метода заключаются в том, что вы можете использовать предварительную сборку заголовков компиляторов плюс вы можете обернуть STL #includes в pragmas, чтобы отключить некоторые предупреждения (например, некоторые заголовки Boost будут вызывать предупреждения при компиляции на уровне 4).

Что вы предпочитаете использовать?

Answer 1

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

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

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

Основное преимущество наличия зависимостей как можно ниже, что рефакторинг становится проще (точнее: возможно)

Большая книга на все это Large Scale C++ Design from Lakos

Answer 2

Полностью согласен с предложением к книге Джона LAKOS в Большой Масштаб C++ Design.

Объявите все заголовки, необходимые для файла, будь то .h или .cpp, в самом файле. Не полагайтесь на побочные эффекты файлов, включенных в другие файлы заголовков.

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

О, еще одна вещь никогда не использует декларации в файле заголовка. Используйте их только в файлах реализации .cpp.

HTH.

веселит,

Роб

Answer 3

Что я могу сделать, это включить все заголовки STL я буду нуждаться во всем проекте в моем одном precompiled header, как правило, по умолчанию Stdafx.h в. Предварительно скомпилированный заголовок является де-факто первым, что нужно создать в проекте, включая все заголовки STL/boost// platform и сторонние библиотеки.

STL & усиление аккуратно расположено в пространствах имен, поэтому они никогда не вызывают никаких смешений или перекрытий.

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

Answer 4

Вы можете объединить эти два метода:

Есть как .cpp - файлы включают в себя, а также добавить его в stdafx.h. Это все равно даст вам оптимизацию PCH.

.cpp - файл по-прежнему нуждается в #include «stdafx.h», так что его независимость является дискуссионным. Однако зависимость явно зависит от состояния, и удаление stdafx.h включает в себя проще, чем найти все недостающие. Кроме того, стандартные заголовки - поскольку все заголовки должны - убедитесь, что они не включены дважды.

---

Вообще, я согласен с вашим подходом, чтобы каждый файл «независимый», т.е. когда .cpp добавляется в другой проект, или .h включен, он заботится о своих зависимостях.

---

Помните, что PCH - это компромисс, он может стать огромным. Наличие большого количества неиспользуемого кода в PCH может фактически замедлить ваши сборки. Быстрые диски очень помогают, хотя :)

Также имейте в виду, что включение предварительно скомпилированных заголовков в MSVC по крайней мере в некоторых версиях фактически меняет обработку: объявления перед #include «stdafx.h» игнорируются, поэтому это необходимо для быть вашим первым комментарием без комментариев. Уродливая ловушка.