<iostream> против.<iostream.h> против.“iostream.h”
https://stackoverflow.com/questions/214230
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
При включении заголовочного файла в C ++, в чем разница между...
1) включение .h по сравнению с невключением .h при упаковке его в < > знаки?
#include <iostream> vs. #include <iostream.h>
2) заключаем имя заголовка в двойные кавычки вместо того, чтобы заключать его в < > знаки?
#include <iostream.h> vs. #include "iostream.h"
Заранее спасибо!
Решение
Короче говоря:
iostream.h устарел - это оригинальная версия Stroustrup, а iostream - это версия комитета по стандартам.Обычно компиляторы указывают им обоим на одно и то же, но некоторые старые компиляторы не будут иметь более старого.В некоторых нечетных случаях они оба будут существовать и отличаться (для поддержки устаревшего кода), и тогда вы должны быть конкретны.
"" против <> просто означает проверку локальных каталогов на наличие заголовка перед переходом в библиотеку (в большинстве компиляторов).
-Адам
Другие советы
Вот достойная ссылка статья.
Подводя итог, приведенная причина:
Версия библиотеки iostream, которую Комитет по стандартам Произведенный продукт немного отличается от реализации CFront. {Надрез}
Чтобы облегчить переход, Комитет по стандартам C ++ объявил, что код в том числе стандартные заголовки C ++ будут использовать директивы include, которые не хватает расширения. Это позволило поставщикам компиляторов отправлять старый стиль Заголовки библиотеки C ++ с расширением .h и заголовками нового стиля без них.
Преимущество не использовать версию .h:
Есть несколько причин, по которым новый код должен быть написан с использованием версия без заголовка файлов заголовков вместо форм .h. Во-первых, непредсказуемость такого кода при компиляции на современном компиляторы. Как упоминалось ранее, результат использования заголовков .h является конкретной реализацией. И со временем вероятность того, что данный компилятор будет иметь доступную старую библиотеку стилей.
Как человек в комитете по стандартам (X3J16), который предложил отказаться от .h, я изначально хотел уладить дискуссию по поводу расширений файлов .h, .H, .hpp, .hxx или .h ++; или желание некоторых, чтобы в стандарте не было никакого смысла, чтобы это было имя файла на диске, чтобы позволить IDE извлекать предварительно скомпилированную информацию заголовка из какого-то внутреннего места, например, файла ресурсов или даже кишок компилятор.
В то время как Unix рассматривал имя файла как одну строку и фактически не распознавал концепцию расширения, в операционных системах DEC существовала традиция отделять имя от расширения и предоставлять расширение «по умолчанию». если это было опущено в определенных контекстах. Вот откуда у меня возникла идея оставить на усмотрение реализации использование любого расширения, которое хочет использовать реализация, и это позволило реализации даже не иметь этого файла на диске. (В то время я был представителем DEC в комитете.)
Различие между стандартными и предварительно стандартными заголовками было дополнительным преимуществом.
Стандартным способом (и единственным, который гарантированно работает) является <iostream>.В gcc, <iostream.h> (который, возможно, потребуется включить как <backward iostream.h="">) извлекает соответствующие объявления в глобальное пространство имен (поэтому вам не нужен std::префикс пространства имен).
"iostream.h" сначала попробовал бы использовать каталог с вашим исходным кодом, поскольку "" предназначен для заголовков вашего проекта.<> всегда следует использовать для системных заголовков, а "" - для ваших собственных заголовков.
Обычно < > используется для файлов системной или стандартной библиотеки, тогда как " " используется для файлов проекта. Я не удивлюсь, если ваш компилятор выполняет поиск локально, а когда он не может его найти, по умолчанию используется стандартная версия библиотеки.
Что касается .h, я не думаю, что это действительно имеет значение, если вы используете C. В C ++ я смутно помню, что была более новая версия и более старая версия, и что без нее это должна была быть новая версия, но я даже не уверен, что старая версия все еще существует.
Это действительно два разных вопроса.
Разница между заголовками .h и extensionless с одинаковым именем является исторической.Те, у которых есть расширение .h, взяты из оригинального стандарта C ++, в котором не было некоторых современных функций, таких как пространства имен и шаблоны.Для нового стандарта было проще включить ту же функциональность в новые заголовочные файлы, чтобы иметь возможность использовать эти новые функции и сохранить старые (.h) файлы для обратной совместимости устаревшего кода.
Разница между #include <...> и формат #include "..." - это порядок, в котором компилятор ищет файлы.Обычно это зависит от реализации, но идея заключается в том, что <> формат просматривается в система сначала включает каталоги, в то время как "" просматривается в том же каталоге что и исходный файл, который #включил его первым.
Простой ответ на первый ответ заключается в том, что iostream.h не существует, по крайней мере, в реализации GCC. Если вы используете * nix, введите
% найти iostream.h
/ USR / включать / C ++ / 3.4.3 / назад / iostream.h
и
% найти iostream
/usr/include/c++/3.4.3/iostream
/ USR / включать / C ++ / 3.4.3 / назад / iostream.h
Как говорится в статье Zee, iostream.h предназначен для обратной совместимости.
Что касается имен стандартных заголовочных файлов C ++, в первые дни (первые 2 года) X3J16 мы столкнулись с аргументом о том, каким должно быть расширение стандартных заголовочных файлов C ++. Я использую в то время различными поставщиками (и под влиянием ограничений, которые некоторые операционные системы накладывают на имена файлов), я считаю, что были .h, .H, .h ++, .hpp, .HXX и, возможно, другие. На собрании группы библиотек я предложил оставить расширение выключенным и оставить его на усмотрение реализации, чтобы предоставить расширение по умолчанию для файла по своему выбору, если его нет в строке включения, или использовать имя в качестве ключа в базе данных предварительно скомпилированные заголовочные файлы при желании. [В то время как Unix-подобные системы рассматривают имя файла и «расширение» как одну строку, я представлял DEC в комитете, и многие операционные системы DEC хранили расширение в каталоге как отдельное поле от имени. Таким образом, в операционных системах DEC существовала давняя традиция применения расширения по умолчанию в зависимости от того, какая программа обращалась к файлу с какой целью. Указание ассемблеру «X, Y = Z» может привести к чтению входного файла Z.MAC (макрос) и записи выходных файлов X.OBJ и Y.LST.] В любом случае, это позволило избежать долгих дебатов без побед, поэтому группа согласился с этим, и Энди Кениг представил выводы группы по этому (среди прочего) всему комитету, который принял его. Я нахожу несколько забавным, что реализации упускают из виду тот факт, что они могут применять расширение по умолчанию по своему выбору (которое, я думаю, было бы полезно для редакторов и других инструментов) и просто оставили расширение вне имени файла.
