Правильный порядок включения как ‹cstdio›, так и ‹stdio.h›?

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

Для других файлов заголовков посмотрите на похожий вопрос здесь, в SO.

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

Таким образом, в этом случае stdio.h является заголовком C и (в моем воображении) ближе к машине, а <cstdio> — это более высокий уровень, стандартная библиотека C++, которую я считаю более абстрактной.

Я сам склонен включать stdio.h перед cstdio, но я не знаю точной аргументации в поддержку этого обоснования.

ОК, после еще нескольких исследований я, наконец, пришел к выводу, что правильно включать заголовок C++ сначала, а затем заголовок C. Например, рассмотрим следующий заголовок C++0x (из gcc):

/usr/include/С++/4.3/tr1_impl/cstdint:

// ...
#define __STDC_LIMIT_MACROS
#define __STDC_CONSTANT_MACROS
#include_next <stdint.h>
// ...

Он определяет два макроса C99 и только затем включает заголовок C99 stdint.h. Причина в том, что в C99 некоторые функции stdint.h являются необязательными и доступны только в том случае, если эти макросы определены. Однако в C++0x все функции stdint.h являются обязательными. Теперь, если я сначала включу C99 stdint.h, а затем cstdint, я не получу обязательные функции C++0x из-за защиты заголовков в stdint.h. Можно было бы возразить, что это вина производителя компилятора, но это было бы неверно. stdint.h — системный заголовок (в данном случае из glibc), который является заголовком C99 и ничего не знает о C++0x (в конце концов, это может быть старая система) или gcc. На самом деле компилятор не может исправить все системные заголовки (в данном случае всегда включать эти функции в режиме C++), но он должен обеспечить поддержку C++0x в этих системах, поэтому вместо этого поставщик использует этот обходной путь.

Насколько я могу судить, ftello() и sprintf() включены в stdio.h.

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

По этой причине зависимости включаемых файлов должны быть включены в включаемый файл, а не полагаться на «пользователя», чтобы обеспечить их правильное включение.

Вы беспокоитесь без уважительной причины. Содержимое <cstdio> является «как бы включением» содержимого <stdio.h> (17.4.1.2 Заголовки/4). Однако объявления и определения (но не макросы) находятся в пространстве имен std.

Поэтому вам может понадобиться написать std::ftello(). Для улучшения портативности добавьте using std::ftello;, и вам не нужно беспокоиться об этом.

Я помещаю наиболее конкретные вещи вверху, а наименее специфичные — внизу. Например, для исходного файла это будет выглядеть так:

1. Предварительно скомпилированный заголовок, если он есть
2. Заголовок для этого исходного файла
3. Проект включает
4. Наиболее специфичные библиотеки, например, библиотеки в этом проекте или библиотеки компании.
5. Наименее специфичные библиотеки, такие как «системные» библиотеки, такие как boost или SDL.
6. Стандартный С++
7. Стандарт С
8. Заголовки операционной системы

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

Другое оправдание заключается в том, что такой порядок не позволяет вам «скрывать» зависимости от других заголовков, то есть эти заголовки не будут автономными при включении из других исходных файлов, поскольку перед ними всегда были включены системные библиотеки.