Как вы организуете свои заголовки STL?

Question

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

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

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

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

Answer 1

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

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

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

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

Великолепная книга обо всем этом: Крупномасштабный дизайн C ++ от Lakos

Answer 2

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

Включите оба .cpp-файла и добавьте их в stdafx.h. Это все равно даст вам оптимизацию PCH.

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

---

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

---

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

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

Answer 3

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

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

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

Answer 4

Полностью согласен с предложением для книги Джона Лакоса Large Scale C ++ Design.

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

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

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

НТН.

ура

Rob