В чем причина заголовков?

Question

Я не совсем понимаю смысл иметь заголовок; похоже, нарушает принцип СУХОГО! Вся информация в заголовке (может быть) содержится в реализации.

Answer 1

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

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

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

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

Answer 2

Архитекторы многих современных языков, таких как Java, Eiffel и C #, полностью согласны с вами - эти языки извлекают метаданные о модуле из реализации. Однако сама по себе концепция заголовков не исключает этого - очевидно, что для компилятора будет простой задачей извлечь файл .h при компиляции, например, .c, точно так же, как компиляторы для других языки делают неявно. Тот факт, что типичные современные компиляторы C не делают этого, не является проблемой проектирования языка - это проблема реализации; очевидно, что пользователи не нуждаются в такой возможности, поэтому ни один из поставщиков компиляторов не потрудится реализовать ее.

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

Если C, C ++ и &, продолжают процветать (по-видимому, они все еще в порядке сегодня ;-), и спрос, как и у вас, на то, что вы не пишете заголовки вручную, растет, в конце концов, разработчики компиляторов должны будут предоставить опцию «генерации заголовков», и «лучшее из обоих миров» не останется теоретическим! -)

Answer 3

Это помогает немного подумать о возможностях компьютеров, которые были доступны, когда, скажем, с, был написан. Основная память измерялась киловольдами, и их не обязательно очень много. Диски были больше, но не намного. Под серьезным хранением подразумевались рулонные ленты, установленные вручную, сварливыми операторами, которые действительно хотели, чтобы вы ушли, чтобы они могли поиграть на охоте. Машина с 1 MIPS быстро кричала . И со всеми этими ограничениями вы должны были поделиться этим. Возможно, с оценкой других пользователей.

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

Answer 4

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

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

Answer 5

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

Поэтому, когда вышел C, обычным шаблоном проектирования для модульности было «никаких проверок вообще». Может быть ограничение, что символы .text могут ссылаться только на .text и .data на .data, но это так. То есть, компиляторы дня обычно обрабатывали один исходный файл за раз, а затем компоновщики собирали их вместе без малейшего уровня проверки ошибок, кроме, если вам повезло, «Я символ функции» против символ данных ".

Итак, идея о том, чтобы компилятор понимал то, что вы вызываете, была несколько новой.

Даже сегодня, если вы делаете полностью поддельный заголовок, никто не поймает вас в большинстве AOT-компиляторов . Умные вещи, такие как языки CLR и Java, действительно кодируют вещи в файлах классов.

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

Answer 6

Для подробного чтения это

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

Стандартная библиотека C и стандартная библиотека C ++ традиционно объявляют свои стандартные функции в заголовочных файлах.

Answer 7

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

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

Заголовочные файлы MOST C содержат подписи вызовов, определения типов и константы.

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

int function target () {
    // Default for shoot
    return FOOT;
}

Answer 8

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

Answer 9

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

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