Инклуды в C++

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

А что по поводу yoursdk? Также создать такую директорию в моём дереве?

А что по поводу yoursdk? Также создать такую директорию в моём дереве?

Если ты и у себя в заголовках хочешь такие полные пути использовать, то проще будет создать такую директорию. При сборке добавляешь в -I путь к корню исходников, и полные пути работают.

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

Но никто не запрещает тебе у себя внутри использовать относительные пути через include с кавычками. Тогда выносить не обязательно.

Про внутри то пофигу. Проблема, как я понимаю, в зависимых модулях, где такие заголовки используются в других заголовках, а не только в реализации. Т.е. как я буду использовать их в своих заголовках, так должен будет использовать их и пользователь SDK.

Публичные хидеры в публичный include, Приватные рядом с файлами реализации.

В приватных можно писать хоть относительные, хоть абсолютные (в понятиях иерархии проекта) - это вкусовщина и принятый код-стайл.

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

Зависимые модули могут зависимости по полным путям включать.

Всегда и везде (и в коде самой библиотеки, и в клиенте)

#include <library/module/header.h>

В проекте код библиотеки лежит, соответственно, в поддиректории library/. В своём коде -I на корень проекта, в клиентском -I на системную include директорию.

Вся реализация должна быть скрыта.

Public:

module/publicapi.h

Private:

module/impl/mystuff.h

Я не об этом спрашивал =) Буду придерживаться того, как slovazap предложил. Спасибо ему.

#include «module/subdirectory/myheader.h»

#include <sdk/header.h>

#include «myheader.h»

+ g++ -Imymodule/subdirectory

Прежде всего, нужно почитать о разнице между #include <> и #include "".

Там разница больше концептуальная, чем реально влияющая на что-либо

Там разница больше концептуальная

Два места поиска вместо одного - это разница, ни на что не влияющая? Ну окей.

Ну тут ты прав. В публичных заголовках должно быть <>

А еще я очень сомневаюсь, что твой SDK не настолько сложен, чтобы заслужить 3-уровневое имя для публичных заголовков.

Т.е. валить всё в одну директорию? Ну совет на уровне, чо..

Т.е. валить всё в одну директорию?

Все публичные заголовки - да. Их и не должно быть много.

Ну совет на уровне, чо..

А то. Посмотри на реальные проекты и посчитай, у скольких из них трехуровневое имя. Я кроме Boost (который вообще странный) навскидку и не вспомню.

<non-normative-section>Многоуровневые имена - обычно признак того, что разработчик хочет сделать по-взрослому. У большинства это проходит вместе с юностью.</non-normative-section>

Собсно моя идея и была в том, чтобы не плодить трёхуровневые заголовки в коде, а иметь нужное количество include directories.. но я обдумаю, может быть имет смысл сделать так, как ты сказал.

Смотри, как делают реальные проекты: GL, X11, SDL, freetype, тысячи их.

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

include/mymodule/subdir/mypublicheader.h (внутри одна строчка):

#include "../../../cpp/subdir/mypublicheader.h"

cpp/subdir/mypublicheader.h
cpp/subdir/myprivateheader.h
cpp/subdir/myimplementation.cpp
cpp/myfoo.cpp

В клиентском коде:

#include <mymodule/subdir/mypublicheader.h>

В коде самой библиотеки:

subdir/myimplementation.cpp:

#include "mypublicheader.h"

myfoo.cpp:

#include "subdir/mypublicheader.h"

При использовании такого модуля из исходников клиент подключает его include-директорию через -I. При установке или создании dev-пакета скрипт проходит по однострочным хедерам в include и устанавливает файл, на который он ссылается, делается это тривиально.