Какое значение имеет файл .h?

Question

Я знаю, что файл .h должен иметь:

• объявления класса,
• прототипы функций,
• и внешние переменные (для глобальных переменных)

Но есть ли смысл делать это .h файлом? Я попытался переименовать мой .h файл в .c файл, и он все еще работает.

We can name our file to be anything, but we choose to name it as a .h file.

Я прав?

Answer 1

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

Что касается именования, лично я видел, по крайней мере, это - *.h, *.H (тьфу), *.hpp, *.hxx, *.hh, *.inl (для обычных заголовков, не просто встроенный код - гадость). Обычно сопровождается соответствующим расширением файла объекта.

Обратите внимание, что стандартные заголовки библиотеки не имеют расширения - например, строка.

Так что все дело вкуса и условностей - что вы будете #include, это будет включено.

Answer 2

Использование .h для именования файлов заголовков - это просто соглашение. Вы также увидите (вероятно, на Unix-подобных платформах):

• .hpp (библиотека Boost использует их)
• .hxx (выглядит как h ++ с наклоненными знаками + - мило, да?)
• .H (Unix чувствителен к регистру, поэтому вы можете отличить их от файлов .h)

Лично я бы настоятельно рекомендовал придерживаться .h. В частности, не используйте .H, иначе вы будете испытывать боль, если вам когда-нибудь понадобится портировать на файловую систему без учета регистра.

Answer 3

Это просто соглашение - «h» означает «заголовок». Однако, как и в случае большинства других соглашений, у вас должна быть очень веская причина, чтобы нарушать ее.

Answer 4

Я подумал, что может быть целесообразно расширить предыдущий ответ для IDE, подобных Visual Studio.

Для простоты следует использовать соглашения об именах, которые распознаются вашей программной IDE.Самые важные правила, которые у него есть, - это те, которые сообщают ему, какой компилятор использовать для каких файлов.Например, .c будет скомпилирован как код C, .cpp как C ++, .cs как C #, .rc компилятором ресурсов и так далее.

Именование чего-либо .h или чего-либо еще, что не охвачено ни одним из стандартных правил выбора компилятора, предотвращает самостоятельную компиляцию файла, что и требуется для заголовочных файлов.Если бы вы попробовали протестировать переименование вашего заголовка в .c в Visual Studio, он был бы скомпилирован для вас, если вы явно не исключили его из сборки.

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

Answer 5

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

Answer 6

Более того, когда у вас есть make-файл, можно сказать что-то вроде: скомпилировать все файлы, оканчивающиеся на .c, в объектные файлы, а не указывать каждый из них по отдельности. Теперь, если вы начнете называть заголовочные файлы расширениями .c, то система make может попытаться скомпилировать заголовочные файлы в объектные файлы ...

Таким образом, наличие отдельных файлов * .h и * .c делает все ясным и понятным не только для программиста, но и для системы make, компилятора и компоновщика.

Answer 7

Наши большие проекты разработки #include cc-файлы из cc-файлов для классов с сотнями методов.Я не согласился с этим, но были причины.

Answer 8

вы компилируете и связываете ваши .h и .cpp с .obj. Затем вы даете .h и .obj (вашу часть) своему партнеру (ваш партнер не знает о реальном коде), и наконец компоновщик объединяет все объекты в исполняемый файл. .h - известный индикатор, который сообщает программисту, что этот файл не содержит определения. мы можем использовать .xyz, если весь мир примет это: -)