#include <iostream.h>가 왜 나쁜가요?

나는 남자가 초보자를위한 C ++ 책에 대해 물었던 또 다른 스레드를 읽고 있었고 , 프로그래머 중 한 명이 이것을 썼습니다.

몇 가지 경고 : "hello world"를 나타내는 모든 책을 피하십시오

#include <iostream.h>

나는 C ++ 책을 열었고 위의 예와 같이 iostream 헤더가 충분히 포함되어 있는지 확인하십시오.

왜 나쁜가요? C ++을 배울 때 고려해야 할 다른 사항은 무엇입니까?

배경 : 저는 C에 능숙하며 다음 학기에는 C ++를 배우기 시작할 것입니다.

헤더 iostream.h는 비표준 헤더이며 모든 플랫폼에 존재하지는 않습니다. 사실 내 시스템에는 존재하지 않습니다 (g ++ 및 GNU libstdc ++ 사용). 따라서 그것을 사용하는 코드는 단순히 내 시스템에서 컴파일되지 않습니다.

iostream.hC ++가 먼저 1998 년에 표준화되기 전에 사용 된 헤더는 일반적으로하지만, 사용되는 98 표준 때문에 <iostream>대신에 <iostream.h>, 후자는 호의에서 떨어졌다 (인 표준이 아닌 모든) 더 이상 모든 플랫폼에서 지원되지 않습니다. 이 코드를 사용하는 코드는 비표준 레거시 코드로 간주해야하며 이식성이 없습니다. 그것을 가르치는 책은 구식이며 피해야합니다.

#include <iostream.h>이 책은 1998 년 첫 C ++ 표준 (표준 헤더는 iostream) 이전에 작성되었다는 표시입니다 .

문제는 오래된 C ++ 코드가 오늘날 나쁜 습관으로 간주되는 방식으로 작성되는 경향이 있다는 것입니다. 특히,

• std::stringand 같은 컨테이너 클래스 대신 C 스타일 배열을 사용 std::vector합니다.
• closeRAII 대신 명시 적 함수 사용 .

iostream.h하지 않 최악의 사전 1998 책이 오해 할 일이 있지만이 될 가능성이 높습니다 먼저 사전 1998 책이 잘못 얻을 것이다 것.

어쩌면 이것은 약간 늦었지만 유닉스 / 리눅스 상자에서 ls /usr/{local/,}include/c++/*또는 그와 비슷한 방식으로 레이아웃과 경로에 따라 그만한 가치가 있습니다. 다음 grep과 같이 문제의 헤더 를 찾는 것으로 파이프 할 수 있습니다 .

ls /usr/{local/,}include/c++/* | grep iostream 

이것은 iostream.h다른 수퍼 스트링뿐만 아니라 룩업을 수반합니다 .

또는 실행 find / -type f -name iostream 2> /dev/null | grep include하거나 locate iostream | grep include(데이터베이스가 최신 상태 인 경우에는을 호출하여 추가 updatedb)-시스템 전체가 아닌 포함도 인쇄하므로 적절하게 조정하십시오. 실제 C ++ 포함 경로는 다음과 같이 쉽게 찾을 수 있습니다.

g++ -v 2>&1| sed -rn 's/.+gxx-include[^=]+=([^ ]+).+/\1/p' # adjust iff empty

Windows 및 기타 시스템에서도 동일합니다. iostream.h시스템에 존재하지 않는 파일은 더 이상 기본적으로 경로를 포함하지만 더 이상 iostream.h소프트 링크 iostream또는 복사본으로 레거시 libc ++ 배포판을 찾을 수 있습니다 . 따라서 이것은 스타일의 문제가 아니라 상황의 문제입니다. 당신은 자신을 배송 할 수 iostream.h단지는 컴파일러가 가입 보이는 포함 경로에 포함되어 있는지 확인해 프로젝트와 <...>헤더.

내 2 센트 만 떨어 뜨려 ".h"와 책의 품질 사이에는 상관 관계가 없다고 생각합니다. 이것은 사소한 구문 문제입니다. 당시에는 실제로 올바른 sytnax였습니다.

iostream.h로 훌륭한 책을 가질 수 있습니까? 예

iostream으로 끔찍한 책을 가질 수 있습니까? 예

나는 책의 질을 판단하기 위해 온라인 사용자 리뷰 (그리고 읽은 후 나의 리뷰)에 의존 할 것이다.