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

Ответ 1

Я также разделяю их, но не строго на расширение, а на доступ к файлу.

Предположим, у вас есть модуль, который управляет информацией о клиенте и использует для этого 2 класса: Customer, CustomerValidityChecker. Также предположим, что другие части вашего приложения должны знать только о классе Customer и что ClientValidityChecker используется только классом Customer для выполнения некоторой проверки. Основываясь на этих предположениях, я храню файлы следующим образом:

Общая папка (или включить папку):

• customer.h

Частная папка (или исходная папка):

• customer.cpp
• customervaliditychecker.h
• customervaliditychecker.cpp

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

Ответ 2

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

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

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

Ответ 3

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

Ответ 4

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

Ответ 5

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

Ответ 6

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

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

Ответ 7

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

Ответ 8

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

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

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

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

Ответ 9

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

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

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

Ответ 10

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