<iostream> против <iostream.h> против "iostream.h"

Question

При включении файла заголовка в C ++, в чем разница между ...

1) включая .h по сравнению с .h, не включая .h при переносе его в <> знаки?

#include <iostream> vs. #include <iostream.h>

2) оборачивать имя заголовка в двойные кавычки или оборачивать его в знаки <>?

#include <iostream.h> vs. #include "iostream.h"

Заранее спасибо!

Answer 1

Короче говоря:

iostream.h устарела - это оригинальная версия Stroustrup, а iostream - версия от комитета по стандартам. Обычно компиляторы указывают им на одно и то же, но некоторые старые компиляторы не будут иметь более старых. В некоторых странных случаях они оба будут существовать и различаться (для поддержки унаследованного кода), и вы должны быть конкретны.

"" против <> просто означает проверку заголовков в локальных каталогах перед тем, как идти в библиотеку (в большинстве компиляторов).

-Adam

Answer 2

Вот приличная ссылка статья.

Подводя итог, приведу причину:

Версия библиотеки iostream, которую Комитет по стандартам Произведенный продукт немного отличается от реализации CFront. {Надрез}

Чтобы облегчить переход, Комитет по стандартам C ++ объявил, что код в том числе стандартные заголовки C ++ будут использовать директивы include, которые не хватает расширения. Это позволило поставщикам компиляторов отправлять старый стиль Заголовки библиотеки C ++ с расширением .h и заголовками нового стиля без.

Преимущество не использования версии .h:

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

Answer 3

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

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

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

Answer 4

Стандартный способ (и единственный гарантированный для работы) - . В gcc (который может потребоваться включить как ) перетаскивает соответствующие объявления в глобальное пространство имен (поэтому вам не нужен префикс std :: namespace).

"iostream.h" будет пытаться сначала из каталога с вашим исходным кодом, поскольку "" предназначен для заголовков из вашего проекта. <> всегда следует использовать для системных заголовков, а "" для собственных заголовков.

Answer 5

Это действительно два разных вопроса.

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

• Разница между #include <...> и #include "..." формат порядок, в котором компилятор ищет файлы. Это вообще зависит от реализации, но Идея в том, что формат <> выглядит в Система включает в себя каталоги в первую очередь, пока "" выглядит в том же каталоге в качестве исходного файла, который #include его первый.

Answer 6

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

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

Answer 7

Что касается имен стандартных заголовочных файлов C ++, в первые дни (первые 2 года) X3J16 мы столкнулись с аргументом о том, каким должно быть расширение стандартных заголовочных файлов C ++. Я использую в то время различными поставщиками (и под влиянием ограничений, которые некоторые операционные системы накладывают на имена файлов), я считаю, что были .h, .H, .h ++, .hpp, .HXX и, возможно, другие. На собрании группы библиотек я предложил оставить расширение выключенным и оставить его на усмотрение реализации, чтобы предоставить расширение по умолчанию для файла по своему выбору, если его нет в строке включения, или использовать имя в качестве ключа в базе данных предварительно скомпилированные заголовочные файлы при желании. [В то время как Unix-подобные системы рассматривают имя файла и «расширение» как одну строку, я представлял DEC в комитете, и многие операционные системы DEC хранили расширение в каталоге как отдельное поле от имени. Поэтому в операционных системах DEC существовала давняя традиция применения расширения по умолчанию в зависимости от того, какая программа обращалась к файлу с какой целью. Указание ассемблеру «X, Y = Z» может привести к чтению входного файла Z.MAC (макрос) и записи выходных файлов X.OBJ и Y.LST.] В любом случае, это позволило избежать долгих дебатов без побед, поэтому группа согласился с этим, и Энди Кениг представил выводы группы по этому (среди прочего) всему комитету, который принял его. Я нахожу несколько забавным, что реализации упускают из виду тот факт, что они могут применять расширение по умолчанию по своему выбору (которое, я думаю, будет полезно для редакторов и других инструментов) и просто оставляют расширение вне имени файла.

Answer 8

Простой ответ на первый ответ заключается в том, что iostream.h не существует, по крайней мере, в реализации GCC. Если вы используете * nix, введите

% locate iostream.h
/usr/include/c++/3.4.3/backward/iostream.h

и

% найти iostream
/usr/include/c++/3.4.3/iostream
/usr/include/c++/3.4.3/backward/iostream.h

Как говорится в статье Zee, iostream.h предназначен для обратной совместимости.