* .h или * .hpp для ваших определений классов

Question

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

Каковы преимущества и недостатки использования *.hpp перед *.h?

Answer 1

Codegear C ++ Builder использует .hpp для файлов заголовков, автоматически генерируемых из исходных файлов Delphi, и файлов .h для ваших «собственных» файлов заголовков.

Итак, когда я пишу заголовочный файл C ++, я всегда использую .h.

Answer 2

В одной из моих работ в начале 90-х мы использовали .cc и .hh для исходного и заголовочного файлов соответственно. Я все еще предпочитаю это всем альтернативам, вероятно, потому что это легче всего напечатать.

Answer 3

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

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

Answer 4

Бьярн Страуструп и Херб Саттер высказывают свое мнение по этому вопросу в своих основных рекомендациях C ++: https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#S-source, которые также ссылаются на последние изменения в стандартном расширении (C ++ 11, C ++ 14 и т. д.)

SF.1: используйте суффикс .cpp для файлов кода и .h для файлов интерфейса, если ваш Y проект уже не следует другому соглашению Причина

Это давняя конвенция. Но последовательность важнее, поэтому если ваш проект использует что-то еще, следуйте этому. Примечание

Это соглашение отражает шаблон общего использования: заголовки чаще используются совместно. с C для компиляции как C ++, так и C, который обычно использует .h, и это проще назвать все заголовки .h вместо того, чтобы иметь разные расширения для только те заголовки, которые предназначены для совместного использования с C. С другой стороны, файлы реализации редко используются совместно с C, поэтому обычно отличается от .c файлов, поэтому обычно лучше назвать все C ++ файлы реализации чего-то другого (например, .cpp).

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

У вашей IDE (если вы ее используете) могут быть сильные мнения о достаточности.

Я не большой поклонник этого соглашения, потому что если вы используете популярную библиотеку, такую ​​как boost, ваша согласованность уже нарушена, и вам лучше использовать .hpp.

Answer 5

К счастью, это просто.

Вы должны использовать расширение .hpp, если вы работаете с C ++, и вы должны использовать .h для C или смешивания C и C ++.

Answer 6

Я использую .h, потому что это то, что использует Microsoft, и что создает их генератор кода. Не надо идти против зерна.

Answer 7

Инструменты и люди легко различают что-то . Вот и все.

При обычном использовании (с наддувом и т. Д.) .hpp - это, в частности, заголовки C ++. С другой стороны, .h только для заголовков не на C ++ (в основном C). Точно определить язык контента, как правило, сложно, поскольку существует много нетривиальных случаев, поэтому такое различие часто делает готовым к использованию инструмент простым в написании. Для людей, получив соглашение, его также легко запомнить и легко использовать.

Однако я хотел бы отметить, что само соглашение не всегда работает, как ожидалось.

• Это не обусловлено спецификацией языков , ни C, ни C ++. Существует много проектов, которые не соответствуют конвенции. Если вам нужно объединить (смешать) их, это может быть хлопотно.
• .hpp сам по себе не единственный выбор. Почему не .hh или .hxx? (Хотя в любом случае вам обычно требуется хотя бы одно обычное правило для имен файлов и путей.)

Я лично использую и .h, и .hpp в своих проектах на C ++. Я не соблюдаю соглашение выше, потому что:

• Языки, используемые каждой частью проектов, четко задокументированы. Нет возможности смешивать C и C ++ в одном модуле (каталоге). Каждая третья библиотека обязана соответствовать этому правилу.
• Соответствующие языковые спецификации и разрешенные языковые диалекты, используемые в проектах, также документируются. (На самом деле, я даже документирую источник используемых стандартных функций и исправления ошибок (в стандарте языка) .) Это несколько важнее, чем различение используемых языков, так как он слишком подвержен ошибкам и стоимость тестирования (например, совместимость компилятора) может быть значительной (сложной и трудоемкой), особенно в проекте, который уже находится в почти чистом C ++. Имена файлов слишком слабы, чтобы справиться с этим.
• Даже для того же диалекта C ++ могут существовать более важные свойства, подходящие для различий. Например, см. Соглашение ниже.
• Имена файлов - это, по сути, фрагменты хрупких метаданных. Нарушение соглашения не так легко обнаружить. Для обеспечения стабильности работы с контентом инструмент должен в конечном итоге зависеть не только от имен. Разница между расширениями - только подсказка. Инструменты, использующие его, также не должны постоянно вести себя одинаково, например, обнаружение языка .h файлов на github.com. (В комментариях может быть что-то вроде shebang , чтобы эти исходные файлы были лучшими метаданными, но они даже не обычны, как имена файлов, поэтому в целом также не надежны.)

Я обычно использую .hpp на заголовках C ++, и заголовки должны использоваться (поддерживаться) только для заголовков , например. как библиотеки шаблонов. Для других заголовков в .h либо имеется соответствующий файл .cpp в качестве реализации, либо это заголовок не-C ++. Последнее тривиально для различения содержимого заголовка людьми (или инструментами с явными встроенными метаданными, если необходимо).

Answer 8

Нет никакого преимущества для какого-либо конкретного расширения, кроме того, что оно может иметь другое значение для вас, компилятора и / или ваших инструментов. header.h является действительным заголовком. header.hpp является действительным заголовком. header.hh является действительным заголовком. header.hx является действительным заголовком. h.header является действительным заголовком. this.is.not.a.valid.header - допустимый заголовок для отказа. ihjkflajfajfklaf является действительным заголовком. Пока имя может быть правильно проанализировано компилятором и файловая система поддерживает его, это допустимый заголовок, и единственным преимуществом его расширения является то, что в него читается.

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

1. Если уже существуют какие-либо установленные правила, следуйте им, чтобы избежать путаницы.
2. Если все исходные файлы в проекте написаны на одном языке, используйте .h. Там нет двусмысленности.
3. Если некоторые заголовки совместимы с несколькими языками, а другие совместимы только с одним языком, расширения основаны на наиболее ограничивающем языке, с которым совместим заголовок. Заголовок, совместимый с C или обоими C & C ++, получает .h, в то время как заголовок, совместимый с C ++, но не C, получает .hpp или .hh или что-то в этом роде.

Это, конечно, всего лишь один из многих способов обработки расширений, и вы не обязательно можете доверять своему первому впечатлению, даже если все кажется простым. Например, я видел упоминание об использовании .h для обычных заголовков и .tpp для заголовков, которые содержат только определения для шаблонных функций-членов класса, с файлами .h, которые определяют шаблонные классы, включая файлы .tpp, которые определяют их функции-члены (вместо заголовка .h, непосредственно содержащего как объявление функции, так и определение). В качестве другого примера, многие люди всегда отражают язык заголовка в его расширении, даже если нет никакой вероятности двусмысленности; для них .h всегда является заголовком C, а .hpp (или .hh, или .hxx и т. д.) всегда является заголовком C ++. И опять же, некоторые люди используют .h для «заголовка, связанного с исходным файлом» и .hpp для «заголовка со всеми встроенными функциями».

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

Answer 9

В "Языке программирования C ++, третье издание Бьярна Страуструпа", обязательной для чтения книге C ++ № 1, он использует * .h. Поэтому я предполагаю, что лучшая практика - использовать * .h.

Впрочем, * .hpp тоже подойдет!

Answer 10

Расширение исходного файла может иметь значение для вашей системы сборки, например, у вас может быть правило в вашем make-файле для файлов .cpp или .c, или ваш компилятор (например, Microsoft cl.exe) может скомпилировать файл как C или C ++ в зависимости от расширения.

Поскольку вы должны указывать полное имя файла для директивы #include, расширение файла заголовка не имеет значения. Вы можете включить файл .c в другой исходный файл, если хотите, потому что это просто текстовое включение. У вашего компилятора может быть возможность вывести предварительно обработанный вывод, который прояснит это (Microsoft: /P для предварительной обработки в файл, /E для предварительной обработки до stdout, /EP для пропуска директив #line, /C сохранить комментарии)

Вы можете использовать .hpp для файлов, которые имеют отношение только к среде C ++, т. Е. Они используют функции, которые не компилируются в C.