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

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

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

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

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

10
c++ include stl

4 ответов

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

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

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

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

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

15

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

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

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

2

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

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

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

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

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

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

2

полностью согласен с предложением для книги Джона Лакоса крупномасштабного дизайна C++.

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

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

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

HTH.

спасибо,

Роб

1