Зачем C ++ нужен отдельный файл заголовка?

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

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

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

1. Чтобы сократить время сборки.
2. Для связывания с кодом, не имея источника определений.
3. Чтобы не отмечать все как «встроенное».

Если ваш более общий вопрос: «Почему C ++ не идентичен Java?», Тогда я должен спросить: «Почему вы пишете C ++ вместо Java?» ;-п

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

Итак, #include - это прямая текстовая подстановка. Если вы определяете все в файлах заголовков, препроцессор в конечном итоге создает огромные копии и вставки каждого исходного файла в вашем проекте и передает их в компилятор. Тот факт, что стандарт C ++ был ратифицирован в 1998 году, не имеет к этому никакого отношения, это тот факт, что среда компиляции для C ++ так близко основана на среде C.

Преобразование моих комментариев в ответ на ваш последующий вопрос:

Как компилятор находит файл .cpp с кодом в нем

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

C ++ делает это так, потому что C сделал это таким образом, поэтому реальный вопрос заключается в том, почему C сделал это таким образом? Википедия немного об этом говорит.

Новые скомпилированные языки (такие как Java, C #) не используют форвардные объявления; идентификаторы автоматически распознаются из исходных файлов и считываются непосредственно из символов динамической библиотеки. Это означает, что файлы заголовков не нужны.

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

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

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

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

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

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

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

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

void SomeFunction() {
    SomeOtherFunction();
}

void SomeOtherFunction() {
    printf("What?");
}

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

void SomeOtherFunction();

void SomeFunction() {
    SomeOtherFunction();
}

void SomeOtherFunction() {
    printf("What?");
}

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

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

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

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

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

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

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

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

Чтобы компенсировать это ограничение, C и C ++ допускают объявления, и эти объявления могут быть включены в модули, которые их используют, с помощью директивы препроцессора #include.

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

Причина того, что информация о привязке не включается в вывод компилятора, проста: она не нужна во время выполнения (любая проверка типа происходит во время компиляции). Это просто потеряло бы место. Помните, что C / C ++ появился в то время, когда размер исполняемого файла или библиотеки имел большое значение.

Что ж, 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, что не относилось конкретно к самому языку.

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

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

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

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

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

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

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

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

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

Что ж, вы можете отлично разработать C ++ без файлов заголовков. Фактически, некоторые библиотеки, которые интенсивно используют шаблоны, не используют парадигму файлов заголовков / кода (см. Boost). Но в C / C ++ нельзя использовать то, что не объявлено. Практический способ справиться с этим - использовать файлы заголовков. Кроме того, вы получаете преимущество совместного использования интерфейса без совместного использования кода / реализации. И я думаю, что это не было предусмотрено создателями C: когда вы используете общие файлы заголовков, вы должны использовать знаменитые:

#ifndef MY_HEADER_SWEET_GUARDIAN
#define MY_HEADER_SWEET_GUARDIAN

// [...]
// my header
// [...]

#endif // MY_HEADER_SWEET_GUARDIAN

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

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

Еще одно бремя для нас, бедных пользователей C ++ ...

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