2016-06-10 2 views
2

Я заметил, что источник популярной библиотеки C++ Cinder имеет отдельные папки src и include, содержащие *.cpp и *.h файлов соответственно. Есть ли преимущество делать это таким образом, а не просто помещать каждый .cpp в тот же каталог, что и его соответствие .h?Есть ли какое-либо преимущество для размещения заголовков в «include» subdir проекта?

+0

Лично я не вижу преимуществ, и мне не нравится это делать. Я думаю, что в C++ файл cpp поставляется с заголовком и не должен быть отделен от него. – Boiethios

ответ

8

Его часто проще структурировать код таким образом, особенно если вы собираетесь экспортировать его как API с предварительно скомпилированными библиотеками. Заголовки (публичные) становятся вашим API, имеет смысл держать их в отдельном месте от источника, поскольку это часть кода, который должен быть распространен вместе с библиотекой.

+3

Я предпочитаю публиковать заголовки API для библиотеки в директории 'include' и других заголовках, которые являются внутренними для библиотеки в директории 'src' вместе с файлами .cc.Это позволяет легко упаковывать двоичные файлы + include dir для пользователей и сдерживать заголовки элементов реализации. –

0

Используемые опции

  • module/*.{cpp,h} - лучше всего подхожу для пространственной местности связанных файлов, худший, когда нужно применять строгую ориентацию API (обратную совместимость, выпуск против патча и т.д.)
  • module/{include/*.h, src/*.{cpp,h}} - хорошо для API фокус, хорошо для пространственной местности, моего предпочтительного выбора
  • include/module/*.h,src/module/*.{cpp,h} - лучше для API фокуса, не очень хорошо для пространственной местности
0

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

Я не думаю, что организация лучше, чем другие, но я могу дать вам два советовали, чтобы помочь вам решить, что лучше для ваших проектов:

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

  • Самое главное, не где файлы заголовков расположены, но как они включены:

    • <> или «»
    • Из внутренних исходных файлов или из внешнего кода, который использует ваши заголовки?
    • По пути к ним или непосредственно по имени файла?

Seing, как вы хотите, чтобы ваши заголовки должны быть записаны при вызове #include поможет вам решить, где это более удобно для Вас, чтобы поместить их.

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