Руководство по стилю Google C ++ рекомендует включать файлы заголовков (.h) в файлы реализации (.cpp, .cc) в следующем порядке:
In dir/foo.cc или dir/foo_test.cc, основной целью которого является реализация или проверка содержимого в dir2/foo2.h, закажите ваши включения следующим образом:
dir2/foo2.h.
A blank line
C system files.
C++ system files.
A blank line
Other libraries' .h files.
Your project's .h files.
Как уже говорилось, такой порядок позволяет увидеть пропущенные зависимостив dir2/foo2.h при компиляции foo -блока, а не других невинных юнитов.Кажется вполне логичным.
Но почему Other libraries' .h files. и Your project's .h files. помещены в конец списка?Теоретически также могут отсутствовать зависимости, которые будут скрыты, включая C system files. и C++ system files. ранее.
Может быть, предполагается, что другие проблемы (файлы заголовков) должны быть обнаружены в связанных файлах реализации?Как насчет библиотек только для заголовков в этом случае?
Другими словами, будет ли следующий порядок включений:
dir2/foo2.h.
A blank line
Other libraries' .h files.
Your project's .h files.
A blank line
C system files.
C++ system files.
будет лучше для более быстрого поиска скрытых зависимостей?
Например, если у меня есть только заголовок, который требует <stdio.h> (но не указано в этом файле).При использовании заказа Google вероятность прямого или косвенного включения <stdio.h> выше, чем когда системные файлы включены на последнем шаге (как я предлагал ранее).Следовательно, низкая вероятность найти скрытую зависимость.Так что же мы выиграем, если включим системные файлы перед другими файлами lib / вашего проекта?
Также неясно, должен ли я использовать рекомендуемый порядок включения файлов в других (определяемых пользователем) заголовочных файлах.