Разделение реализации и заголовков

Кмк это целиком и полностью личные представления о прекрасном

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

Это вкусовщина. Мне лично такое не нравится. Я люблю в одном каталоге располагать.

Имело бы смысл (и может растёт оттуда), если предусматривается несколько реализаций.

Я обычно публичные заголовочники складываю в modulename/include, а исходники и приватные заголовочники в modulename/src. Другие модули подключают -I modulename/include и не могут случайно использовать приватные заголовочники.

Чтобы скопировать только заголовочники можно воспользоваться маской имени файлов по расширению.

Особенно когда в новомодном стиле у хедеров нет никакого расширения.

Придумывать для этого убогую иерархию не нужно.

То-то сырцы в системе разделены на /usr/include и всякие другие места.

У каждого додика своя методика, но в целом, ИМНО, для больших проектов выделение заголовков в отдельный каталог оправдано - это удобней и разработчикам и пользователям.

Для хедер-онли либ, или для толстых хедеров с каими нить шаблонами, иногда в хедере (например a.hpp) оставляют только обьявления, а реализации уносят в какой нить a_impl.hpp который инклюдится в a.hpp. Причем a_impl.hpp утаскивают в другой каталог.

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

Все *cpp располагаются в поддиректории impl, на один уровень ниже в дереве исходников относительно соответствующих заголовочных файлов

Где это может быть удобно?

Обычно там только системно-зависимые или обертки для «конкурирующих реализаций», в зависимости от доступных в конкретной системе. К ним еще в довесок были «приватные заголовки». Либо абстрагирование от особенностей использования и конфигурации сборок «программных продуктов»(ТМ) на основе одних и тех же сорцов, когда сервер, клиент и какой-нибудь хаб – отдельные приложения (раньше еще и с коробками) и/или отдельные «бренды» разных там лицензирующих этот софт поставщиков.

Например, протокол FIX для обмена финансовой инфой вроде бы стандартный… Но каждый «участник рыночка» имеет своих тараканов на тему «да мы, тоже используем это сообщение, но есть нюанс…». В итоге, кодовая база может состоять из таких вот оберток, абстрагирующих различия разных бирж и банков. Особенно часто это встречалось до появления модулей в репозиториях. Ну или… кто-то довел этот «паттерн» до абсурда.

Это всратый подход для размещения файлов. Чтобы скопировать

Дело вообще не в копировании. А в разделении реализаций.

Придумывать для этого убогую иерархию не нужно.

Разбираться в чужом коде насратом просто кучей не нужно.

impl каталоги нужны только если этих самых impl будет несколько.

А вот в принципе отделять сорцы от инклудов имеет смысл, если разрабатывается API или есть потенциал на вынесение API из основного решения. Так тупо удобнее делать пакет поставки - открытые интерфейсы в одной директории, закрытые в другой. Тогда вот появляется src/impl директории, это уже на вкус и цвет фломастеры разные как именно назвать.

Дело вообще не в копировании. А в разделении реализаций.
Разбираться в чужом коде насратом просто кучей не нужно.

В предложенном подходе нет никакого разделения реализаций, там просто насрато в двух местах. При прочих равных удобнее когда .cxx и .h лежат рядом. А чтобы было действительно удобно, эти пары организуются в иерархию. А вот impl/*.cpp это тавтология, потому что .cpp это по определению имплементация.

Такое может иметь смысл, если отделены именно публичные заголовки, тогда можно прописать путь к этому каталогу к себе в -I и пользоваться библиотекой без предварительной инсталляции (причём вышеупомянутые «_impl.hpp» с реализациями шаблонов в этом контексте тоже могут считаться публичными, если они транзитивно инклудятся в пользовательский код).

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

Чтобы в include path не было лишнего.

как еще вариант

скорость компиляции

но имхо с современными компиляторами и модулями это уже не актуально

скорость компиляции

размещение сырцов по каталогам?! Нет, не влияет.

Скорость компиляции – это при замене инклюдов на forward declaration и pimpl, когда скорость пересборки роляет для быстрого выкатывания и щастья зайказчиков и манагеров, а ждать пока наскирдованный слоптимизаторами template.cpp «все в одном» cоберется на третьи сутки некогда.

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

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