Зачем размещать заголовки в отдельном каталоге?

Ответ 1

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

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

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

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

Ответ 2

Сохраняет структуру папок. Заголовки и исходные файлы отличаются друг от друга и используются для разных вещей, поэтому имеет смысл их разделить. Из этой точки зрения вопрос в основном такой же, как "почему исходные файлы и документация входят в разные папки"? Компьютер очень несовместим с тем, что вы вкладываете в папки, а какие нет, папки - по большей части - просто удобная абстракция из-за того, как мы, люди, разбираем, сохраняем и вспоминаем информацию.

Также существует тот факт, что файлы заголовков остаются полезными даже после того, как вы построили, то есть, если вы создаете библиотеку и кто-то хочет использовать эту библиотеку, им понадобятся файлы заголовков - - не исходные файлы - поэтому он объединяет эти файлы заголовков - захватывает материал в bin и материал в include и не требует просеивания через src - намного проще.

Ответ 3

Я предпочитаю помещать их в один каталог. Причина:

Файл спецификации интерфейса и исходный файл (ы), реализующий этот интерфейс, принадлежат к той же части проекта. Скажем, у вас есть subsystemx. Затем, если вы поместите файлы subsystemx в каталог subsystemx, subsustemx является автономным.

Если есть много включенных файлов, вы можете сделать subsystemx/include и subsystemx/source, но затем я утверждаю, что если вы поместите определение class Foo в foo.hpp и foo.cpp, вы обязательно захотите увидеть оба из них (или, по крайней мере, имеют возможность сделать это легко) вместе в списке каталогов. Поиск всех файлов, связанных с foo

ls foo*

Поиск всех файлов реализации:

ls *.cpp

Поиск всех файлов декларации:

ls *.hpp

Простой и чистый.

Ответ 4

Кроме того (аргументированная?) полезность для сохранения вещей упорядоченно, полезно в других проектах и ​​т.д., есть одно очень нейтральное и объективное преимущество: время компиляции.

В частности, в большом проекте с целым рядом файлов в зависимости от путей поиска для заголовков (.c/.cpp файлов с использованием #include "headername.h", а не #include "../../gfx/misc/something/headername.h", и компилятор передал правильные параметры, чтобы быть в состоянии чтобы усвоить это), вы резко сокращаете количество записей, которые необходимо отсканировать компилятором в поисках правильного заголовка. Поскольку большинство компиляторов запускаются отдельно для каждого скомпилированного файла, они должны читать в списке файлов на пути include и искать правильные заголовки для каждого скомпилированного файла. Если на пути включения есть куча .c,.o и других нерелевантных файлов, поиск среди них занимает пропорционально дольше.

Ответ 5

Короче говоря, несколько причин:

• Поддерживаемый код.
• Код хорошо разработан и опрятен.
• Более быстрое время компиляции (иногда, для незначительных изменений).
• Более легкое разделение интерфейсов для документации и т.д.
• Циклическую зависимость во время компиляции можно избежать.
• Легко просматривать.

Взгляните на статью Упорядочить файлы кода на C и С++, что объясняет это хорошо.