Как создать заголовочный файл c

09) Создание заголовочных файлов - Разные уроки по Программированию

Создание заголовочных файлов .h

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

    В языке С++ существует возможность разбить проект на отдельные файлы кода (содержащие наборы логически связанных между собой процедур и функций) которые будут связанны друг с другом через специальными ссылочными файлами.

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

Пример:

    Для создания отдельного файла с функциям или процедурами и в C++ необходимо создать 2 файла с одним и тем же именем например но разными расширениями.

1) Файл содержащий код процедур и функций MyFaileForFunck.cpp 

2) Файл заголовка функции будет содержать ссылку на функцию в виде ее заголовка MyFaileForFunck.h

Подключение Файлов к проекту.

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

    Туда где лежит файл с расширением  cpp

    Если заголовочный файл лежит в той же папке что проект мы должны в операторе #include использовать двойные кавычки. Если мы положили файл в папку Include нашей среды разработки значит мы должны использовать <имя файла >  косые скобки.

    После подключения данного заголовочного файла нам станет доступна функция или функции описанные в данном файле.

Компилирование заголовочных файлов или документация на халяву / Хабр

Для кого эта статья

Введение

Когда я только начинал изучать этот проект, мне сразу посоветовали построить по нему документацию с помощью doxygen’а. Но по каким-то причинам дружба с этим инструментом не заладилась, и вспомнил в следующий раз я о нем уже спустя годы.

Предыстория

Проблема

Решение в опции PREDEFINED?

Проблема в коде!

Но вовремя остановился я, ибо понял в чем отличие его от компилятора. Цели у них весьма разные (и у доксигена в некотором роде даже сложнее), потому что ему надо не только понять cpp-файлы, но проделать тоже самое и с заголовочными файлами, чтобы потом красиво показать это все пользователю, т.е. по-файлово. И отсюда вытекает кое-что интересное, о чем я раньше не думал: компилятор не интересуется заголовочными файлами, на вход ему поступает “единица трансляции”, или выход препроцессора с уже отработанными директивами #include. Позволю себе перефразировать это таким образом — компирятор имеет дело с заголовочными файлами лишь косвенно, так сказать, в контексте единицы трансляции. И компилирует его в этом самом контексте. Отсюда следует неутешительный вывод — заголовочный файл может быть неправильным сам по себе, но становиться правильным в контексте своего использования, и компилятор ничего не скажет вам об этом!

А вот с doxygen’ом это не проходит — заголовочный файл анализируется как самостоятельный, самодостаточный документ с исходным кодом. И если в нем не хватает объявлений используемых сущностей (которые появляются в контексте использования данного заголовочного файла), то doxygen будет ошибаться. И очень похоже, что именно эта болезнь постигла наш проект.

Так какая же ошибка, неуловимая для компилятора, затаилась в заголовочном файле? Это недостоющии #include директивы тех файлов, где были определены пресловутые макросы. Т.е. при компиляции cpp-файлов все определения попадали в текущую единицу трансляции каким-нибудь обходным путем, а не через “проблемный” заголовочный файл. После этого открытия в нашей команде прошло совещание, с главным вопросом на повестке дня “и что с этим делать, собственно говоря?”. Вопрос был решен в пользу того, что подобное поведение — отсутствие всех нужных инклудов — ошибка. Основной довод весьма прост — заголовочный файл потенциально может быть включен куда угодно, и значит должен быть настолько самодостаточен, чтобы скомпилироваться.

Решение — “компиляции заголовочных файлов”

Теперь пришло время поговорить непосредственно о компиляторе, используемом в нашей команде.
По историческим причинам это ms visual studio, стандарта аж 2008-го года. Но буквально перед финалом данной истории успешно завершился проект перевода вычислительного ядра системы под GNU/Linux. И естественным образом в данной среде был выбран в качестве компилятора GCC, версии 4.6.
И начал терзать его просьбами я, мол скомпилируй мне заголовки. И долго сопротивлялся он… пока не прогнулся.
Вдумчивое чтение его man’а указало мне опцию -I, с помощью которой GCC можно указать путь, от которого стоит искать инклуды в кавычках.
Здесь же следует отметить один немаловажный факт, в проекте своем мы уже давно (и весьма успешно) придерживаемся правила “указывай путь к файлу в инклуде от корня проекта”. Эта дисциплинированность позволила обойтись единственной опцией -I.
Далее осталось подать на вход gcc все заголовочные файлы проекта. Но здесь вышла некоторая заминка связанная с нежеланием gcc принимать на вход выход команды ls через конвейер. Но решение оказалось еще тривиальнее, gcc и так осуществлял поиск входных файлов по переданной маске.
Таким образом, команда
g++ -I ./ */*/*/*/*.h */*/*/*.h */*/*.h
полностью осуществляет валидацию всех заголовочных файлов библиотеки.
Следующий раз gcc начал сопротивляться, если ему дать на вход *.inl файлы. Помогли опции -c (только компиляция без линковки), и -x c++ (явное задания языка программирования).
Итоговая команда, используемая для валидации заголовочных (*.inl файлы мы решили оставить в покое) файлов:
gcc -c -x c++ -I ./ */*/*/*/*.h */*/*/*.h */*/*.h

Ну что ж, осталось исправить ошибки и пользоваться doxygen’ом.

И, в общем-то, еще, наверняка, можно кое-что улучшить, например, прикрутить сюда cmake, но основная мысль данного поста именно в необходимости “компиляции заголовочных файлов” для борьбы с, казалось бы, странным поведением doxygen’а. Так что на этом остановлюсь, пока не утомил последнего самого усидчивого читателя ;)

Вместо выводов

Естественно, в комментариях жду конструктивную критику, исправления, дополнения моих в меру кривых команд и вопросы.

C: Заголовочные файлы - Linux FAQ

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

Заголовочные файлы подключаются к файлам исходного кода приложения по мере необходимости с помощью директивы #include.

#include "sums.h"

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

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

#ifndef SUMS_H
#define SUMS_H
…
#endif /*SUMS_H*/

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

#if x86_64
#include "system64.h"
#elif x86
#include "system32.h"
#endif

Пример

В данном простом примере функция вывода приветствия находится в отдельном файле исходного кода (hello.c), который подключается к основному файлу исходного кода программы (hellomain.c) с помощью заголовочного файла (hello.h).

Это содержимое файла исходного кода hello.c:

1. #include <stdio.h>

2.  

3. void print_hello(void)

4. {

5.         printf("Hello worldn");

6. }

Загрузить исходный код примера

Это — содержимое файла исходного кода hello.h:

1. #ifndef HELLO_H

2. #define HELLO_H

3.  

4. void print_hello(void);

5.  

6. #endif /*HELLO_H*/

Загрузить исходный код примера

А это — содержимое файла исходного кода hellomain.c:

1. #include <stdio.h>

2. #include "hello.h"

3.  

4. int main()

Многофайловые программы. Урок 21 курса "Основы языка C"

Объектный код

Запуск gcc позволяет обработать файл с исходным кодом препроцессором и далее скомпилировать его. Однако при этом сам инструмент gcc не компилирует файл исходного кода в конечный исполняемый файл. Он компилирует его в объектный файл, после чего вызывает так называемый линковщик, или компоновщик. Но зачем надо сначала получать объектный файл, а потом из него уже исполняемый? Для программ, состоящих из одного файла, такой необходимости нет. Хотя при желании здесь также можно отказаться от компоновки, если выполнить команду gcc с ключом -c:

 gcc -c hello.c

В результате получится файл с расширением *.o. Чтобы получить из объектного файла исполняемый, надо использовать ключ -o:

 gcc -o hello hello.o 

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

Компиляция программы, состоящей из нескольких файлов исходного кода

Рассмотрим пример. Пусть в одном файле определена пара функций, а в другом, содержащем функцию main(), осуществляется их вызов.

Файл superprint.c:

#include <stdio.h>   void l2r(char **c, int n) { int i, j; for(i=0; i<n; i++, c++) { for (j=0; j<i; j++) printf("\t"); printf ("%s\n",*c); } }   void r2l(char **c, int n) { int j; for(; n>0; n--, c++) { for (j=1; j<n; j++) printf("\t"); printf ("%s\n",*c); } }

Файл main.c:

#include <stdio.h>   #define N 5   int main () { char strs[N][10]; char *p[N];   int i;   for(i=0; i<N; i++) { scanf("%s", strs[i]); p[i] = &strs[i][0]; }   l2r(p, N); r2l(p, N); }

В теле функции main() заполняется массив, состоящий из строк, а также массив указателей на эти строки. Далее в функции l2r() и r2l() передаются ссылки на первый элемент массива указателей и значение символической константы N. Эти функции осуществляют вывод элементов массива строк с отступами.

Чтобы получить исполняемый файл этой программы, надо сначала получить объектные файлы из исходных:

 gcc -c superprint.c gcc -c main.c 

Тоже самое можно сделать за один вызов gcc:

 gcc -c superprint.c main.c

Или даже вот так, если в каталоге находятся только файлы текущего проекта:

 gcc -c *.c

В любом случае в каталоге появятся два объектных файла: superprint.o и main.o. Далее их можно скомпилировать в один исполняемый файл так:

 gcc -o myprint main.o superprint.o

или так:

 gcc -o myprint *.o

Обратите внимание на то, что в данном случае обязательно требуется указывать имя исполняемого файла. Такой вариант недопустим:

 gcc -o main.o superprint.o

Если теперь запустить файл myprint, то программа будет ожидать ввода пяти слов, после чего выведет их на экран два раза по-разному (с помощью функций l2r() и r2l()):

Задумаемся, каким образом в представленной выше программе функция main() "узнает" о существовании функций l2r() и r2l(). Ведь в исходном коде файла main.c нигде не указано, что мы подключаем файл superprint.c, содержащий эти функции. Действительно, если попытаться получить из main.c отдельный исполняемый файл, т.е. скомпилировать программу без superprint.c:

 gcc main.c

, то ничего не получиться. Компилятор сообщит об ошибке вызова неопределенных идентификаторов. Получить из файла superprint.c отдельный исполняемый файл вообще невозможно, т.к. там отсутствует функция main(). А вот получить из этих файлов отдельные объектные файлы можно. Представим, что одни объектные файлы как бы "выставляют наружу" имена определенных в них функций и глобальных переменных, а другие - вызовы этих имен из тел других функций. Дальше объектные файлы "ожидают", что имена будут связаны с их вызовами. Связывание происходит при компиляции исполняемого файла из объектных.

Создание заголовочных файлов

Продолжим разбирать приведенную выше программу. Что будет, если в функции main()осуществить неправильный вызов функций l2r() и r2l()? Например, указать неверное количество параметров. В таком случае создание объектных файлов пройдет без ошибок, и скорее всего удастся получить исполняемый файл; но вот работать программа будет неправильно. Такое возможно потому, что ничего не контролирует соответствие вызовов прототипам (объявлениям) функций.

Куда правильней сообщать о неверном вызове функций уже при получении объектного файла. Поэтому хотя можно обойтись и без этого, но очень желательно сообщать функции main()прототипы функций, которые из нее вызываются. Это можно сделать, прописав объявления функций в файле main.c:

… void l2r (char **c, int n); void r2l (char **c, int n); main () { …

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

А теперь представим, что программа у нас несколько больше и содержит десяток файлов исходного кода. Файл aa.c требует функций из файла bb.c, dd.c, ee.c. В свою очередь dd.c вызывает функции из ee.c и ff.c, а эти два последних файла активно пользуются неким файлом stars.c и одной из функций в bb.c. Программист замучится сверять, что чего вызывает откуда и куда, где и какие объявления надо прописывать. Поэтому все прототипы (объявления) функций проекта, а также совместно используемые символические константы и макросы выносят в отдельный файл, который подключают к каждому файлу исходного кода. Такие файлы называются заголовочными; с ними мы уже не раз встречались. В отличие от заголовочных файлов стандартной библиотеки, заголовочные файлы, которые относятся только к вашему проекту, при подключении к файлу исходного кода заключаются в кавычки, а не скобки. Об этом упоминалось в предыдущем уроке.

Итак, более грамотно будет не добавлять объявления функций в файл main.c, а создать заголовочный файл, например, myprint.h и поместить туда прототипы функций l2r() и r2l(). А в файле main.c следует прописать директиву препроцессора:

 #include "myprint.h" 

В принципе смысла подключать myprint.h к файлу superprint.c в данном случае нет, т.к. последний не использует никаких сторонних функций, кроме стандартной библиотеки. Но если планируется расширять программу и есть вероятность, что в файле superprint.c будут вызываться сторонние для него функции, то будет надежней сразу подключить заголовочный файл.

Обратим внимание еще на один момент. Стоит ли в описанном в этом уроке примере выносить константу N в заголовочный файл? Здесь нельзя дать однозначный ответ. Если ее туда вынести, то она станет доступна в обоих файлах, и поэтому можно изменить прототипы функций так, чтобы они принимали только один параметр (указатель), а значение N будет известно функциям их заголовочного файла. Однако стоит ли так делать? В функции r2l() второй параметр изменяется в процессе ее выполнения, что делать с константой будет невозможно. Придется переписывать тело функции. Кроме того, вдруг в последствии нам захочется использовать файл superprint.c в другом проекте, где будут свои порядки, и константы N в заголовочном файле не найдется.

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

Особенности использования глобальных переменных

Помните, если можно отказаться от использования глобальных переменных, то лучше это сделать. Желательно стремиться к тому, чтобы любой файл проекта, скажем так, "не лез к соседу за данными, а сосед не разбрасывал эти данные в виде глобальных переменных". Обмен данными между функциями должен осуществлять за счет передачи данных в качестве параметров и возврата значений с помощью оператора return. (Массивов это не касается.)

Однако в языке программирования C есть проблема. С помощью return можно вернуть только одно значение. Но могут быть случаи, когда функция должна изменить несколько переменных (здесь не имеются ввиду элементы массива). В таком случае без глобальных переменных обойтись сложно.

• Если в файле aa.c объявлена переменная за пределами любой функции (например, так: intcount), то она является глобальной для всех файлов проекта. Чтобы получить значение этой переменной в файле aa.c достаточно просто указать ее имя (если в функции нет локальной переменной с тем же именем). Чтобы получить значение из других файлов, надо указать, что имеется в виду глобальная переменная, а не локальная. Делается это с помощью ключевого слова extern (например, extern count).
• Бывают ситуации, когда в одном файле для нескольких содержащихся в нем функций нужна глобальная переменная. Но эта переменная не должна быть доступна функциям, содержащимся в других файлах. В таком случае глобальная переменная объявляется с ключевым словом static (например, static int count). Тем самым мы как бы скрываем глобальную переменную.

Напишите простые наглядные примеры, использования глобальных функций:

1. Объявите глобальную переменную в одном файле, а получите ее значение в другом файле (выведите на экран).
2. Объявите в одном файле статическую глобальную переменную. Выведите ее значение на экран из функции данного файла. Попытайтесь сделать это из функции другого файла.
3. Создайте две глобальные переменные в одном файле. В другом файле напишите функцию, которая меняет их значение.

Курс с решением части задач:
android-приложение, pdf-версия

Что должно быть в с-файле, а что должно быть в h-файле? / Хабр

Отчасти это дело вкуса, поэтому, кому интересно как это делаю я, добро пожаловать под кат.

Несмотря на то, что «вся правда» о h-файлах содержится в соответствующем разделе описания препроцессора gcc, позволю себе некоторые пояснения и иллюстрации.

Итак, если дословно, заголовочный файл (h-файл) — файл содержащий Си декларации и макро определения, предназначенные для использования в нескольких исходных файлах (с-файлах). Проиллюстрируем это.

Легко заметить, что функции 1 и 2, а так же макрос 2, упомянуты в обоих файлах. И, поскольку, включение заголовочных файлов приводит к таким же результатам, как и копирование содержимого в каждый си-файл, мы можем сделать следующее:

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

• Если нам нужно использовать функциональность, которую реализуют функции 1 и 2 где то еще, то Да
• Если макрос 2, предназначен только для использования в файлах Unit1.c и Unit2.c, то ему не место в интерфейсном файле

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

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

Спасибо за внимание к материалу.

как создать заголовочный файл в dev c++

Я создаю заголовочный файл в первый раз в dev c++ Я создал add.h и add.cpp в соответствии с правильным форматом. Я не знаю, где их хранить, и когда я использую заголовок, он показывает много ошибок

#ifndef ADD_H #define ADD_H class Add { ... }; #endif 

#include "add.h" 

#include "add.h" 

#include "add.h" 

 int факториал (целое число) { int итерация, factorial = 1; for (итерация = 1; итерация <= число; итерация ++) { факториал = факториал * итерация; } возврат факториала; } 

 #include  #include "factorial.h" используя пространство имен std; int main () { cout << "Добро пожаловать в учебники DataFlair!" << endl << endl; int positive_integer; cout << "Введите положительное целое число:" << endl; cin >> positive_integer; cout << "Факториал" << положительное_ целое число << ":" << факториал (положительное_ целое число) << endl; возврат 0; }