Заголовочный файл (иногда головной файл, англ. header file ), или подключаемый файл — в языках программирования Си и C++ файл, содержащий определения типов данных, структуры, прототипы функций, перечисления, макросы препроцессора. Имеет по умолчанию расширение .h; иногда для заголовочных файлов языка C++ используют расширение .hpp. Заголовочный файл используется путём включения его текста в данный файл директивой препроцессора #include .
Заголовочный файл в общем случае может содержать любые конструкции языка программирования, но на практике исполняемый код (за исключением inline функций в C++) в заголовочные файлы не помещают. Например, идентификаторы, которые должны быть объявлены более чем в одном файле, удобно описать в заголовочном файле, а затем его подключать по мере надобности.
Основная цель заголовочных файлов — вынесение описания нестандартных типов и функций за пределы основного файла с кодом. На этом же принципе построены библиотеки: в заголовочном файле перечисляются содержащиеся в библиотеке функции и используемые ею структуры/типы, при этом исходный текст библиотеки может находиться отдельно от текста программы, использующей функции библиотеки или вообще быть недоступным.
Что такое cpp и h и как их применять и использовать на c++
Например, в языках программирования Си и C++ функции стандартной библиотеки по сложившейся традиции объявляют в заголовочных файлах. Подробнее смотрите Стандартная библиотека языка Си и Стандартная библиотека C++.
Преимущества использования
В большинстве современных языков программирования, корректность функционирования программ зависит от ее собственных компонентов (подпрограмм), а эти компоненты могут распространяться в виде файлов, компилируемых отдельно. Если подпрограмму необходимо использовать где-то еще, где она не определена, возникает необходимость в использовании предварительного объявления или прототипа функции. Например, функция определена следующим образом в одном исходном файле:
int add(int a, int b) { return a + b; }
Она может быть объявлена (при помощи прототипа функции), а затем можно ссылаться на нее в другом исходном файле:
extern int add(int, int); int triple(int x) { return add(x, add(x, x)); }
Тем не менее, такое упрощенное приближение требует, чтобы программист обеспечил объявление функции для add в двух местах — в файле, содержащем ее выполнение, и в файле, в котором она используется. В случае изменения определения функции программист должен не забыть обновить все прототипы, использованные в программе.
Заголовочный файл является решением этой проблемы. В заголовочном файле модуля объявляется каждая функция, объект и тип данных, являющиеся частью интерфейса вызова модуля — например, в этом случае заголовочный файл может содержать только объявление функции add . Каждый исходный файл, ссылающийся на функцию add , должен использовать директиву #include для подключения заголовочного файла:
/* File add.h */ #ifndef ADD_H #define ADD_H int add(int, int); #endif /* ADD_H */
/* File triple.c */ #include «add.h» int triple(int x) { return add(x, add(x, x)); }
Это облегчает поддержку: при изменении определения должно быть обновлено лишь одно объявление (то, которое находится в заголовочном файле). К исходному файлу также можно подключать заголовочный файл, содержащий определение, используемые в исходниках. Это позволяет компилятору проверять объявление и определение на корректность.
Язык Си с нуля — Урок 47 — Многофайловые проекты. Создание и подключение. Заголовочные файлы.
/* File add.c */ #include «add.h» int add(int a, int b) { return a + b; }
Обычно заголовочные файлы применяются только для более чёткого определения интерфейса и обычно содержат комментарии, поясняющие способы использования компонентов, объявленных в файле. В приведенном примере использованные подпрограммы выделены в отдельные исходные файлы, которые должны компилироваться отдельно (исключением в языках Си и C++ являются встраиваемые функции, которые зачастую включаются в заголовочный файл из-за того, что в большинстве случаев использования не получается правильно раскрыть встраиваемую функцию без обращений к их определению во время компиляции).
Альтернативные варианты
Заголовочные файлы — не единственное решение проблем доступа к идентификаторам, объявленным в различных файлах. У них есть недостаток, заключающийся в необходимости вносить изменния в двух местах (исходный и заголовочный файлы) каждый раз при изменении определения. Некоторые более новые языки (такие как Java) вместо заголовочных файлов используют схемы наименования, позволяющие компилятору использовать исходные файлы, связанные с интерфейсами и использованиями классов.
Ссылки
Источник: www.sbup.com
Руководство Google по стилю в C++. Часть 2
Часть 1. Вступление
Часть 2. Заголовочные файлы
Часть 3. Область видимости
…
Все мы при написании кода пользуемся правилами оформления кода. Иногда изобретаются свои правила, в других случаях используются готовые стайлгайды. Хотя все C++ программисты читают на английском легче, чем на родном, приятнее иметь руководство на последнем.
Эта статья является переводом части руководства Google по стилю в C++ на русский язык.
Исходная статья (fork на github), обновляемый перевод.
Заголовочные файлы
Желательно, чтобы каждый .cc файл исходного кода имел парный .h заголовочный файл. Также есть известные исключения из этого правила, такие как юниттесты или небольшие .cc файлы, содержащие только функцию main().
Правильное использование заголовочных файлов может оказать огромное влияние на читабельность, размер и производительность вашего кода.
Следующие правила позволят избежать частых проблем с заголовочными файлами.
Независимые заголовочные файлы
Заголовочные файлы должны быть самодостаточными (в плане компиляции) и иметь расширение .h. Другие файлы (не заголовочные), предназначенные для включения в код, должны быть с расширением .inc и использоваться в паре с включающим кодом.
Все заголовочные файлы должны быть самодостаточыми. Пользователи и инструменты разработки не должны зависеть от специальных зависимостей при использовании заголовочного файла. Заголовочный файл должен иметь блокировку от повторного включения и включать все необходимые файлы.
Предпочтительно размещать определения для шаблонов и inline-функций в одном файле с их декларациями. И эти определения должны быть включены (include) в каждый .cc файл, использующий их, иначе могут быть ошибки линковки на некоторых конфигурациях сборки. Если же декларации и определения находятся в разных файлах, включение одного должно подключать другой. Не выделяйте определения в отдельные заголовочные файлы (-inl.h). Раньше такая практика была очень популярна, сейчас это нежелательно.
Как исключение, если из шаблона создаются все доступные варианты шаблонных аргументов или если шаблон реализует функционал, используемый только одним классом — тогда допустимо определять шаблон в одном (и только одном) .cc файле, в котором этот шаблон и используется.
Возможны редкие ситуации, когда заголовочный файл не самодостаточный. Это может происходить, когда файл подключается в нестандартном месте, например в середине другого файла. В этом случае может отсутствовать блокировка от повторного включения, и дополнительные заголовочные файлы также могут не подключаться. Именуйте такие файлы расширением .inc. Используйте их парой и старайтесь чтобы они максимально соответствовали общим требованиям.
Блокировка от повторного включения
Все заголовочные файлы должны быть с защитой от повторного включения посредством #define. Формат макроопределения должен быть: _ _ _H_.
Для гарантии уникальности, используйте компоненты полного пути к файлу в дереве проекта. Например, файл foo/src/bar/baz.h в проекте foo может иметь следующую блокировку:
#ifndef FOO_BAR_BAZ_H_ #define FOO_BAR_BAZ_H_ . #endif // FOO_BAR_BAZ_H_
Предварительное объявление
По возможности, не используйте предварительное объявление. Вместо этого делайте #include необходимых заголовочных файлов.
Определение
«Предварительное объявление» — декларация класса, функции, шаблона без соответствующего определения.
- Предварительной объявление может уменьшить время компиляции. Использование #include требует от компилятора сразу открывать (и обрабатывать) больше файлов.
- Предварительное объявление позволит избежать ненужной перекомпиляции. Применение #include может привести к частой перекомпиляции из-за различных изменений в заголовочных файлах.
// b.h: struct B <>; struct D : B <>; // good_user.cc: #include «b.h» void f(B*); void f(void*); void test(D* x) < f(x); >// calls f(B*)
- Старайтесь избегать предварительного объявления сущностей, объявленных в другом проекте.
- Когда используйте функцию, объявленную в заголовочном файле, всегда #include этот файл.
- Когда используйте шаблон класса, предпочтительно #include его заголовочный файл.
Встраиваемые (inline) функции
Определяйте функции как встраиваемые только когда они маленькие, например не более 10 строк.
Определение
Вы можете объявлять функции встраиваемыми и указать компилятору на возможность включать её напрямую в вызывающий код, помимо стандартного способа с вызовом функции.
Использование встраиваемых функций может генерировать более эффективный код, особенно когда функции маленькие. Используйте эту возможность для get/set функций, других коротких и критичных для производительности функций.
Чрезмерное использование встраиваемых функций может сделать программу медленнее. Также встраиваемые функции, в зависимости от размера её, могут как увеличить, так и уменьшить размер кода. Если это маленькие функции, то код может быть уменьшен. Если же функция большая, то размер кода может очень сильно вырасти. Учтите, что на современных процессорах более компактный код выполняется быстрее благодаря лучшему использованию кэша инструкций.
Хорошим правилом будет не делать функции встраиваемыми, если они превышают 10 строк кода. Избегайте делать встраиваемыми деструкторы, т.к. они неявно могут содержать много дополнительного кода: вызовы деструкторов переменных и базовых классов!
Ещё одно хорошее правило: обычно нет смысла делать встраиваемыми функции, в которых есть циклы или операции switch (кроме вырожденных случаев, когда цикл или другие операторы никогда не выполняются).
Важно понимать, что встраиваемая функция не обязательно будет скомпилирована в код именно так. Например, обычно виртуальные и рекурсивные функции компилируются со стандартным вызовом. Вообще, рекурсивные функции не должны объявляться встраиваемыми. Основная же причина делать встраиваемые виртуальные функции — разместить определение (код) в самом определении класса (для документирования поведения или удобства чтения) — часто используется для get/set функций.
Имена и Порядок включения (include)
Вставляйте заголовочные файлы в следующем порядке: парный файл (например, foo.h — foo.cc), системные файлы C, стандартная библиотека C++, другие библиотеки, файлы вашего проекта.
Все заголовочные файлы проекта должны указываться относительно директории исходных файлов проекта без использования таких UNIX псевдонимов как . (текущая директория) или .. (родительская директория). Например, google-awesome-project/src/base/logging.h должен включаться так:
#include «base/logging.h»
Другой пример: если основная функция файлов dir/foo.cc иdir/foo_test.cc это реализация и тестирование кода, объявленного в dir2/foo2.h, то записывайте заголовочные файлы в следующем порядке:
- dir2/foo2.h.
- — Пустая строка
- Системные заголовочные файлы C (точнее: файлы с включением угловыми скобками с расширением .h), например , .
- — Пустая строка
- Заголовочные файлы стандартной библиотеки C++ (без расширения в файлах), например , .
- — Пустая строка
- Заголовочные .h файлы других библиотек.
- Файлы .h вашего проекта.
Такой порядок файлов позволяет выявить ошибки, когда в парном заголовочном файле (dir2/foo2.h) пропущены необходимые заголовочные файлы (системные и др.) и сборка соответствующих файлов dir/foo.cc или dir/foo_test.cc завершится ошибкой. Как результат, ошибка сразу же появится у разработчика, работающего с этими файлами (а не у другой команды, которая только использует внешнюю библиотеку).
Обычно парные файлы dir/foo.cc и dir2/foo2.h находятся в одной директории (например, base/basictypes_test.cc и base/basictypes.h), хотя это не обязательно.
Учтите, что заголовочные файлы C, такие как stddef.h обычно взаимозаменяемы соответствующими файлами C++ (cstddef). Можно использовать любой вариант, но лучше следовать стилю существующего кода.
Внутри каждой секции заголовочные файлы лучше всего перечислять в алфавитном порядке. Учтите, что ранее написанный код может не следовать этому правилу. По возможности (например, при исправлениях в файле), исправляйте порядок файлов на правильный.
Следует включать все заголовочные файлы, которые объявляют требуемые вам типы, за исключением случаев предварительного объявления. Если ваш код использует типы из bar.h, не полагайтесь на то, что другой файл foo.h включает bar.h и вы можете ограничиться включением только foo.h: включайте явно bar.h (кроме случаев, когда явно указано (возможно, в документации), что foo.h также выдаст вам типы из bar.h).
Например, список заголовочных файлов в google-awesome-project/src/foo/internal/fooserver.cc может выглядеть так:
#include «foo/server/fooserver.h» #include #include #include #include #include «base/basictypes.h» #include «base/commandlineflags.h» #include «foo/server/bar.h»
Бывают случаи, когда требуется включение заголовочных файлов в зависимости от условий препроцессора (например, в зависимости от используемой ОС). Такое включение старайтесь делать как можно короче (локализованно) и размещать после других заголовочных файлов. Например:
#include «foo/public/fooserver.h» #include «base/port.h» // For LANG_CXX11. #ifdef LANG_CXX11 #include #endif // LANG_CXX11
Источник: habr.com
Идентификация типа во время исполнения (RTTI)
Используя идентификацию типа времени исполнения (run-time type identification — RTTI) можно определить тип объекта во время исполнения программы. Для этого используется функция typeid. Для использования этой функции необходимо включить заголовочный файл typeinfo.h. Общая форма записи функции typeid имеет следующий вид:
Здесь объект является объектом, чей тип требуется определить. Функция typeid возвращает ссылку на объект типа typeinfo, который описывает тип объекта объект. (В проекте стандарта С++ этот тип называется type_info.) Класс typeinfo определяет следующие публичные члены:
bool operator== (const typeinfo
bool operator!= (const typeinfo
bool before(const typeinfo
const char *name() const;
Перегруженные операторы == и != обеспечивают сравнение типов. Функция before() возвращает истину, если вызываемый объект стоит выше в иерархии объектов, чем объект, используемый в качестве параметра. Функция before() предназначена большей частью для внутреннего использования. Возвращаемое ею значение не имеет ничего общего с иерархией классов или наследованием. Функция name() возвращает указатель на имя типа.
Когда функция typeid применяется к указателю на базовый класс полиморфного класса, она автоматически возвращает тип объекта, на который указывает указатель, в том числе любой класс, выведенный из базового класса. (Как уже говорилось, полиморфным классом называется класс, содержащий хотя бы одну виртуальную функцию.)
 |
ПАМЯТКА: Указатель обязательно должен быть разыменован. Следует также установить режим поддержки RTTI в опциях компилятора. |
Следующая программа демонстрирует использование функции typeid
Программа выдаст следующий результат на экран:
Typeid of i is int
p is pointing to an object of type BaseClass
p is pointing to an object of type Derived1
p is pointing to an object of type Derived2
Как уже отмечалось, применение функции typeid к указателю на базовый класс полиморфного типа позволяет определить фактический тип объекта, на который указывает указатель во время исполнения программы. Поэкспериментируем теперь, закомментировав виртуальную функцию f() в базовом классе, и посмотрим на результат.
RTTI не является тем средством, которое используется всякой программой. Однако при работе с полиморфными типами она позволяет знать тип объекта в любой ситуации.
Источник: www.c-cpp.ru