Отдельные папки" include "и" src " для кода уровня приложения?

У нас есть система сборки, которая автоматически генерирует наши файлы Makefile. Одна вещь, которую он делает, - это рекурсивно спускать любые подкаталоги и строить их как библиотеки, связывая их вместе с объектами основного каталога, чтобы сделать приложение. (На практике эти "подкаталоги" обычно являются символическими ссылками.) Библиотеки статичны, если только имя каталога не заканчивается на ".Итак". Одна вещь, которая хороша в этом, заключается в том, что полная сборка нашей системы, которая имеет много исполняемых файлов, не должна многократно скомпилируйте общие библиотеки.

однако в результате этого нет разделения заголовков и источников. И это никогда не было проблемой. Честно говоря, я думаю, что это лучше, потому что заголовки и исходные файлы имеют общее расположение, и вы можете захватить каталог и знать, что у вас есть все, что вам нужно, чтобы использовать его. Он также отлично работает с функцией Subversion "externals" и аналогичными функциями в других VCSs.

одно последнее место где разъединение include / src сбой - это если вы используете генераторы кода, такие как flex, bison или gengetopts. Выяснить, где эти инструменты должны размещать свои выходы, чтобы они были построены, сложно, если вы распространили вещи.

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

многое зависит от размера проекта. До нескольких десятков файлов или около того, хранение их в одном каталоге, как правило, более удобно. Для большего приложения, которое включает сотни или тысячи файлов, вы начинаете искать способы их разделения (хотя в проектах, над которыми я работал, это было сделано больше по функциональным линиям, чем src/include). В промежутке между ними, это, вероятно, под вопросом.

Я этого не делаю; кажется, в этом мало пользы. Поскольку заголовки, как правило, имеют другое расширение от исходных файлов, вы можете показать их отдельно, если вы действительно чувствуете необходимость - Visual Studio делает это по умолчанию, но я отключаю его, так как я предпочитаю видеть их вместе

Я почти всегда создаю папки include и src для разделения исходного кода. Я думаю, что это делает папку менее загроможденной, и файлы легче найти в моей IDE. Но я думаю, это просто вопрос вкуса.

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

на мой взгляд, нет явного преимущества ни для того, ни для другого. Я, наконец, решил сохранить файлы программы и заголовков вместе, потому что мой редактор (Visual SlickEdit) предоставляет дополнительные ссылочные функции, когда они не разделены.

Я размещаю include (заголовок) и исходные файлы в одном каталоге (папке). Я создаю разные папки для разных тем. Я расстраиваюсь при попытке найти файлы заголовков (во время отладки, а также для исследования). В некоторых магазинах есть только две папки: source и includes. Эти каталоги имеют тенденцию расти экспоненциально. Повторное использование кода становится кошмаром в лучшем случае.

ИМХО, я считаю, что организация по теме лучше. Каждая папка темы должна быть встроена по крайней мере в одна библиотека. Различные проекты могут легко включать темы путем поиска или включения папок. Проекты должны включать только библиотеки. Движки Smart build могут отображать папки тем в качестве зависимостей. Это ускоряет процесс сборки.

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

Это только мое мнение, ваш пробег может варьироваться.

Нижняя Строка: источники и заголовки, которые все еще меняются, идут в /src. Код, который кристаллизовался, должен войти /lib & /include (на самом деле вы могли бы держать все .libи .hs в /lib).

• держите собственные источники и заголовки вместе, если они (a) специфичны для этого проекта или (b) еще не были учтены как общая библиотека.
• как только определенные источники в основном проекте были учтены как (относительно стабильная) библиотека, поместите .a или .lib на /lib, и его заголовок открытого интерфейса в /include.
• все сторонние библиотеки и их заголовки открытого интерфейса также входят в /lib & /include.

как отмечают другие, он часто более совместим для инструментов / IDEs для доступа .h/.c из одной папки. Но с организационной точки зрения может быть полезно отделить изменяющийся локальный код от стабильного кода lib.

У нас есть система сборки, которая использует это правило. Эта система сборки sconspiracy набор скриптов для настройки SCons и посвященный миру C++. Вы можете увидеть пример, который использует эти инструменты:fw4spl