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

Это действительно проблема с областью.

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

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

Да, на этом этапе (через 10 лет после первый стандарт C ++ и спустя 20 лет после того, как он начал серьезно расти в использовании), легко спросить, почему у него нет надлежащей модульной системы. Очевидно, что любой новый язык, который разрабатывается сегодня, не будет работать, как C ++. Но это не относится к C ++.

Точка C ++ должна быть эволюционной, гладкой продолжением существующей практики, только добавляя новые возможности без (слишком часто) нарушения вещей, которые адекватно работают для пользователя community

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

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

C ++ был ратифицирован в 1998 году, так почему он спроектирован таким образом? Какие преимущества имеет отдельный файл заголовка?

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

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

Второе преимущество: он позволяет обмениваться интерфейсами без совместного использования кода между разными единицами (разные разработчики, команды, компании и т. Д.) [ ! d1]

Некоторые люди считают заголовочные файлы преимуществом:

• Утверждается, что он включает / обеспечивает / позволяет разделять интерфейс и реализацию, но обычно это не так. Заголовочные файлы полны деталей реализации (например, переменные-члены класса должны быть указаны в заголовке, даже если они не являются частью общедоступного интерфейса), а функции могут и часто задаются inline в объявление класса в заголовке, снова разрушая это разделение.
• Иногда говорят, что улучшать время компиляции, потому что каждая единица перевода может обрабатываться независимо. И все же C ++ - это, вероятно, самый медленный язык, который существует, когда дело доходит до времени компиляции. Одной из причин является много многократных включений одного и того же заголовка.

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

И C ++ сохранил эту систему для обратной совместимости.

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

Однако одно из предложений для C ++ 0x состояло в том, чтобы добавить правильную систему модулей, позволяя компилировать код, подобный .NET или Java, в более крупные модули, все в одном и без заголовков. Это предложение не делало сокращения в C ++ 0x, но я считаю, что он все еще находится в категории «мы бы хотели сделать это позже». Возможно, в TR2 или аналогичном.

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

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

Скажем, у меня есть foo.cpp, и я хочу использовать код из файлов bar.h / bar.cpp.

Я могу # включить «bar.h» в foo.cpp, а затем запрограммировать и скомпилировать foo.cpp, даже если bar.cpp не существует. Файл заголовка выступает в качестве обещания компилятору, что классы / функции в bar.h будут существовать во время выполнения, и у него есть все, что ему нужно знать.

Конечно, если функции в bar.h не имеют тел, когда я пытаюсь связать свою программу, тогда она не будет связываться, и я получу ошибку.

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

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

К моему (ограниченному - я вообще не разработчик C), это связано с C. Помните, что C не знает, какие классы или пространства имен есть, это всего лишь одна длинная программа.

Например, следующее должно приводить к ошибке компилятора:

  void SomeFunction () {SomeOtherFunction ();  } void SomeOtherFunction () {printf («Что?»);  }  

Ошибка должна заключаться в том, что «SomeOtherFunction не объявлен», потому что вы вызываете ее перед ее объявлением. Одним из способов его устранения является перемещение SomeOtherFunction над SomeFunction. Другой подход заключается в том, чтобы сначала объявить подпись функции:

  void SomeOtherFunction ();  void SomeFunction () {SomeOtherFunction ();  } void SomeOtherFunction () {printf («Что?»);  }  

Это позволяет компилятору узнать: посмотрите где-нибудь в коде, есть функция SomeOtherFunction, которая возвращает void и не принимает никаких параметров. Итак, если вы используете код, который пытается вызвать SomeOtherFunction, не паникуйте и вместо этого ищите его.

Теперь представьте, что у вас есть SomeFunction и SomeOtherFunction в двух разных файлах .c. Затем вам нужно включить # SomeOther.c в Some.c. Теперь добавьте некоторые «частные» функции в SomeOther.c. Поскольку C не знает частных функций, эта функция будет доступна и в Some.c.

Здесь находятся файлы .h. Они определяют все функции (и переменные), которые вы хотите " Экспортировать 'из файла .c, доступ к которому можно получить в других файлах .c. Таким образом, вы получаете что-то вроде области Public / Private. Кроме того, вы можете предоставить этот файл .h для других людей, не передавая свой исходный код - файлы .h также работают с скомпилированными .lib-файлами.

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

Это было C, хотя. В C ++ введены классы и частные / общедоступные модификаторы, поэтому, хотя вы все еще можете спросить, нужны ли они, C ++ AFAIK по-прежнему требует объявления функций перед их использованием. Кроме того, многие разработчики C ++ являются или являются C devleopers, а также используют свои концепции и привычки для C ++ - зачем менять то, что не сломано?