Следующее довольно типично ...
third-party library
release
obj
debug
obj
include
src
sublib 1
sublib 2
mylibrary
release
obj
debug
obj
include
src
sublib 1
sublib 2
myapp
release
obj
debug
obj
subapp 1
subapp 2
mylittleapp
release
obj
debug
obj
По сути, подпапки для подпроектов являются общими для более крупных проектов, но в большинстве случаев у определенного проекта есть папки для src, include и т. Д. Папка для каждой конфигурации сборки является общей, и в ней хранятся файлы obj и другие промежуточные файлы в подпапке хорошая идея. Может быть заманчиво помещать подпроектные папки в папки obj, но обычно это не нужно - папки obj не должны быть хорошо организованы, поэтому единственное беспокойство вызывает конфликт имен файлов, и лучшим решением для этого является использование уникальных исходных имен файлов в пределах (как минимум) каждого проекта.
Папки «include» должны в IMO содержать только заголовки, которые будут # включены другими проектами - внутренние заголовки находятся в папке «src».
Поместить элементы пользовательского интерфейса в отдельную папку - неплохая идея, если она достаточно большая. Я видел, как пользовательский интерфейс выполнялся как отдельный статически связанный проект верхнего уровня, и здесь я имею в виду специфическое для приложения, а не (например) wxWidgets. Обычно, тем не менее, этот уровень разделения - это подпроект , если , то стоит вообще отделиться. То, как вы разделяете подпроекты, в большей степени зависит от конкретных блоков приложения, поэтому оно зависит от того, лучше ли обрабатывать элементы пользовательского интерфейса как отдельный блок или как отдельные чанки, смешанные с логикой конкретной задачи.
Пространства имен - не самая используемая языковая функция, возможно, потому, что многие люди используют «использование» настолько, что не имеют большого значения. Пространство имен для проекта основной библиотеки имеет смысл, но я не видел привязки подпапок к пространствам имен 1: 1. У меня лично есть пространство имен, которое охватывает большую часть моего библиотечного кода, с парой подпространств имен для вещей, редко используемых в общем, но часто используемых в нескольких местах (например, «побитовые» пространства имен). Под-пространства имен ограничены одной парой источник / заголовок, поэтому нет необходимости во вложенных папках. Большая часть выбора для конкретной библиотеки выполняется путем включения правильного заголовка, за исключением того, что я обычно включаю лот через заголовок верхнего уровня основного проекта.
По сути, пространства имен - это способ избежать конфликтов имен. Они не обязательно ассоциируются с абстракциями, функциональными блоками или чем-то еще. В конкретном проекте вам, вероятно, лучше просто убедиться, что имена не конфликтуют. Как и в случае пространства имен "std", можно поместить lot материала в одно пространство имен.
Тем не менее, как вы говорите, это не окончательный ответ - конечно, есть небольшие различия и совершенно разные подходы.