vs. vs.“iostream.h”

Question

C ++에 헤더 파일을 포함시킬 때 ... 차이점은 무엇입니까?

1) .h를 포함하여 .h를 포함하지 않음.

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

2) 헤더 이름을 이중 따옴표로 래핑하는 것과 <> 표지판으로 래핑합니까?

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

미리 감사드립니다!

Answer 1

요컨대 :

iostream.h는 더 이상 사용되지 않습니다 - 원래 Stroustrup 버전이며 iostream은 표준위원회의 버전입니다. 일반적으로 컴파일러는 둘 다 같은 것을 가리키지 만 일부 오래된 컴파일러에는 이전 컴파일이 이전 컴파일을 가지지 않습니다. 일부 홀수 경우에 그들은 존재하고 다르게 (레거시 코드를 지원하기 위해), 당신은 구체적이어야합니다.

"" "대 <>는 단순히 라이브러리 (대부분의 컴파일러에서)에 가기 전에 헤더의 로컬 디렉토리를 점검하는 것을 의미합니다.

-아담

Answer 2

여기에 괜찮은 링크가 있습니다 기사.

요약하기 위해 주어진 이유는 다음과 같습니다.

표준위원회가 생산 한 ioStream 라이브러리의 버전은 CFront 구현과는 상당히 다릅니다. {한조각}

전환을 용이하게하기 위해 C ++ 표준위원회는 표준 C ++ 헤더를 포함한 코드가 확장이없는 지시문을 포함한다고 선언했습니다. 이를 통해 컴파일러 공급 업체는 .h 확장자와 새로운 스타일 헤더가없는 구식 C ++ 라이브러리 헤더를 배송 할 수있었습니다.

.h 버전을 사용하지 않는 이점 :

.h 양식 대신 extensionless 버전의 헤더 파일을 사용하여 새 코드를 작성 해야하는 몇 가지 이유가 있습니다. 첫 번째는 최신 컴파일러에서 컴파일 될 때 그러한 코드의 예측 불가능 성입니다. 앞에서 언급 한 바와 같이, .h 헤더를 사용한 결과는 구현 특이 적이다. 그리고 시간이 지남에 따라, 주어진 컴파일러가 구식 라이브러리를 사용할 수있을 가능성이 줄어들 것입니다.

Answer 3

.H를 떠나지 않았다고 제안한 표준위원회 (X3J16)의 사람으로서, 나의 원래 의도는 .h, .h, .hpp, .hxx 또는 .h ++ 파일 확장에 대한 토론을 해결하는 것이 었습니다. 또는 IDE가 사전 컴파일 된 헤더 정보를 리소스 파일이나 장의 내장과 같은 곳에서 어떤 곳에서 가져올 수 있도록 디스크의 파일 이름이라는 표준에 영향을 미치지 않는다는 소망 컴파일러.

UNIX는 파일 이름이 단일 문자열로 간주되었고 실제로 확장의 개념을 인식하지 못했지만 DEC 운영 체제는 이름을 확장자와 분리하고 특정 상황에서 생략 된 경우 "기본 확장"을 공급하는 전통을 가졌습니다. 그곳에서 구현이 사용하려는 모든 확장자를 사용하기 위해 구현에 맡기는 아이디어를 얻었으며 구현에 디스크에 파일이 없을 수도 있습니다. (당시위원회에서 DEC의 대표였습니다.)

표준과 사전 표준 헤더를 차별화하는 것이 추가적인 이점이었습니다.

Answer 4

표준 방법 (그리고 일할 수있는 유일한 방법)은u003Ciostream> . GCC에서u003Ciostream.h> (다음과 같이 포함해야 할 수도 있습니다u003Cbackward/iostream.h> )는 관련 선언을 글로벌 네임 스페이스로 가져옵니다 (따라서 std :: 네임 스페이스 접두사가 필요하지 않음).

"iostream.h"는 소스 코드를 사용하여 디렉토리에서 먼저 시도합니다. ""는 프로젝트의 헤더를위한 것이기 때문입니다. <>은 항상 시스템 헤더에 사용되어야하며 ""자신의 헤더에는 ""에 사용해야합니다.

Answer 5

일반적으로 <>은 시스템 또는 표준 라이브러리 파일에 사용되며 "" "는 프로젝트 파일에 사용됩니다. 컴파일러가 로컬로 검색하고 찾을 수없는 경우 표준 라이브러리 버전으로 기본적으로 검색해도 놀라지 않을 것입니다.

.h는 C ++에서 C ++에서 실제로 중요하다고 생각하지 않습니다. C ++에서는 새로운 버전과 이전 버전이 있었으며 H가 없으면 새 버전이되어야한다는 것을 모호하게 기억합니다. 그러나 이전 버전이 여전히 존재한다고 확신조차하지 않습니다.

Answer 6

이것들은 실제로 두 가지 다른 질문입니다.

• 이름이 같은 .H와 Extensionless 헤더의 차이점은 역사적입니다. .h 확장 기능이있는 것은 원래 C ++ 표준에서 나온 것으로 네임 스페이스 및 템플릿과 같은 현대적인 기능이 없었습니다. 새로운 표준이 새로운 헤더 파일에 동일한 기능을 새로운 기능을 사용하여 이러한 새로운 기능을 사용하고 기존 (.h) 파일을 레거시 코드의 역 호환성을 유지할 수 있도록하는 것이 더 간단했습니다.

• #include <...>와 #include "..."형식의 차이는 컴파일러가 파일을 찾는 순서입니다. 이것은 일반적으로 구현에 따라 다르지만 아이디어는 시스템에서 <> 형식 모양에 먼저 디렉토리가 포함되며 "" "는 #inincted를 먼저 포함시킨 소스 파일과 동일한 디렉토리에서 보입니다.

Answer 7

첫 번째 답변에 대한 간단한 답변은 적어도 GCC 구현에 iOStream.h가 존재하지 않는다는 것입니다. 당신이 *nix에 있다면, 입력하십시오

% 찾기 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는 후진 호환성을위한 것입니다.

Answer 8

표준 C ++ 헤더 파일의 이름과 관련하여 X3J16의 초기 (처음 2 년)에 표준 C ++ 헤더 파일에 대한 확장이 무엇인지에 대한 논쟁에 직면했습니다. 당시 다양한 공급 업체가 사용하고 (일부 운영 체제가 파일 이름에 배치 한 제약 조건에 의해 영향을 받음) .h, .h, .h ++, .hpp, .hxx 등이 있다고 생각합니다. 도서관 그룹 회의에서 나는 확장을 꺼내고 구현에 맡겨서 포함 라인에없는 경우 선택의 기본 파일 확장을 제공하거나 이름을 데이터베이스의 키로 사용하는 것입니다. 원하는 경우 사전 컴파일 된 헤더 파일. [유닉스와 같은 시스템이 파일 이름과 '확장'을 단일 문자열로 취급하는 동안, 나는위원회에서 DEC를 대표했으며, 많은 DEC 운영 체제는 디렉토리의 확장을 이름과 별도의 필드로 저장했습니다. 따라서 DEC 운영 체제는 어떤 프로그램이 어떤 목적으로 파일에 액세스했는지에 따라 기본 확장을 적용하는 강력한 전통을 가졌습니다. 어셈블러 'x, y = z'에게 입력 파일 z.mac (매크로) 및 출력 파일을 쓰면 출력 파일 x.obj 및 y.lst를 작성할 수 있습니다. 어쨌든, 길고 유리한 토론을 피할 수 있으므로 그룹은 그룹이 발생할 수 있습니다. Andy Koenig는 이에 대한 그룹의 결론을 전체위원회에 수락 한 전체위원회에 제시했습니다. 구현이 선택의 기본 확장을 적용 할 수 있다는 요점 (편집자 및 기타 도구에 유용 할 것이라고 생각)가 파일 이름에서 확장을 남겼다는 점을 놓친다는 사실을 다소 즐겁게 생각합니다.