Зачем использовать #include_next в проекте?

Чтобы указать документацию iOS на заголовках Wrapper:

#include_next не различает <file> и "файл", а также не проверяет, что указанный вами файл имеет одинаковый имя как текущий файл. Он просто ищет файл с именем, начиная с каталогом в пути поиска после того, где текущий файл был найден.

Использование `#include_next 'может привести к большой путанице. Мы рекомендуем он будет использоваться только тогда, когда нет другой альтернативы. В частности, это не должны использоваться в заголовках, относящихся к конкретной программе; Это следует использовать только для внесения глобальных поправок в соответствии с fixincludes.

Итак, два вопроса, что такое #include_next, и почему вам когда-нибудь понадобится его использовать?

Ответы

Ответ 1

Используется, если вы хотите заменить заголовок по умолчанию одним из своих собственных решений, например, скажем, вы хотите заменить "stdlib.h". Вы бы создали файл stdlib.h в своем проекте, и это будет включено вместо заголовка по умолчанию.

#include_next используется, если вы хотите добавить некоторый материал в stdlib.h, а не полностью заменить его. Вы создаете новый файл stdlib.h, содержащий:

#include_next "stdlib.h"
int mystdlibfunc();

И компилятор не будет включать ваш stdlib.h снова рекурсивно, как в случае с простым #include, но скорее продолжит в других каталогах файл с именем "stdlib.h".

Ответ 2

Это удобно, если вы поддерживаете несколько версий чего-то. Например, я пишу код, поддерживающий PostgreSQL 9.4 и 9.6. Существует ряд внутренних изменений API, в основном новые аргументы существующих функций.

Заголовки совместимости и функции обертки

Я мог писать заголовки совместимости с static inline оберточными функциями с новыми именами для всего, в основном API-интерфейсом обертки, где я использую имя обертки во всем моем коде. Скажите something_compat.h с помощью:

#include "something.h"

static inline something*
get_something_compat(int thingid, bool missing_ok)
{
    assert(!missing_ok);
    return get_something(thingid);
}

но уродливо разбрасывать _compat или любые суффиксы везде.

Заголовок обертки

Вместо этого я могу вставить заголовок совместимости в путь включения при создании против старой версии, например. compat94/something.h:

 #include_next "something.h"

 #define get_something(thingid, missing_ok) \
 ( \
     assert(!missing_ok), \
     get_something(thingid) \
 )

поэтому остальная часть кода может просто использовать подпись 9.6. При построении против 9.4 мы будем префикс -Icompat94 в путь поиска заголовка.

Уход требуется для предотвращения множественной оценки, но если вы используете #include_next, вы явно не против полагаться на gcc. В этом случае вы также можете использовать выражения .

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

Альтернативы

Или быть разумным человеком, использовать С++ и использовать перегруженные функции и встроенные функции шаблонов: p