2017-11-23 15 views
2

컴파일러가 헤더 파일을 열지 않고도 헤더 파일을 볼 수 있기 때문에 헤더의 첫 번째 줄에는 항상 #include guard가 있어야한다는 것을 알게되었습니다 (링크를 더 이상 찾을 수 없습니다). 따라서 헤더 파일이 이미 포함 된 경우 파일을 다시 열면 파일이 열리지 않으므로 건물 프로세스가 빨라집니다.
하지만 항상 모든 파일의 시작 부분에 주석 블록이 있습니다. 그래서 내 질문에, # 가드 블록 전에 코멘트 블록을 작성해야합니까?댓글 블록 앞 또는 뒤에 # 가드가 포함되어 있습니까?

/////////////////////// 
// Name:  code.h 
// Author:  Me 
// Date:  dd.mm.yyyy 
// Description: This code executes a specific task 
/////////////////////// 

#ifndef CODE_H_ 
#define CODE_H_ 

... 

#endif 

또는 인도 표준시 스타일이 더 나은 :

이 스타일 더 좋아

#ifndef CODE_H_ 
#define CODE_H_ 

/////////////////////// 
// Name:  code.h 
// Author:  Me 
// Date:  dd.mm.yyyy 
// Description: This code executes a specific task 
/////////////////////// 

... 

#endif 

아니면 전혀 중요하지 않습니다?

+0

나노초의 안전을 정말로 원한다면, 반드시 첫 번째 가능한 장소에 써야합니다! ;) 그런 것들은 모든 소프트웨어 사용자들의 삶에 정말로 중요합니다. 그것이 당신이 가진 가장 중요한 문제 중 하나라면, 당신은 아주 좋은 위치에 있습니다! BTW : 컴파일러는 어쨌든 파일을 열어야합니다 ... Include gard는 다른 곳에 표시되지 않습니다. – Klaus

+0

@Klaus 나는 이것이 정말로 큰 것이 아니라는 것을 알고 있지만, 나는 호기심이 생겼다. :) –

+0

전에. 선 처리기가 처리해야하는 라인이 적을수록 좋습니다. 필자는 직선과 라인 수를 출력하는 컴파일러 (Watcom)를 사용했지만 항상 1 : 100 이상의 비율로 사용되었습니다. – EJP

답변

4
내 경험에서

others'

는 시간이 걸릴 파일의 구문 분석 및 독서 아니지만, 다양한 최적화 및 코드 생성이

그래서에 파일을 열 전달한다는 것입니다 inlucde 가드는 대규모 프로젝트의 빌드 타임에는 무시할 수 있어야합니다.

즉, 의 절차가 아니기 때문에이 될 수 없습니다.

그래서 어느 스타일을 선 택해도 실제로 의견을 기반으로합니다.


또 다른 흥미로운 댓글이 here을 발견

하나 옛적의 경비를 포함 확인하기 위해 파일을 매번 개방 할 정도로 바보 하나 또는 두 개의 컴파일러가되었을 수 있습니다. 이 밀레니엄에서 제작 된 컴파일러는 파일의 테이블을 보관하고 경비원을 포함시키고 파일을 열기 전에 해당 파일을 참조 할 수 있기 때문에 컴파일러가 작성하지 않습니다.

자세한 내용은 File-wide include-guards을 참조하십시오.

+0

질문은 경비원을 포함하지 않겠다는 것 또는 주석 블록 전후에 묻습니다. 그러므로 최적화와 코드 생성 패스는 여기서는 관련이 없습니다. – Klaus

+1

@Klaus 네,하지만 요점은 파싱과 파일 읽기가 OP를 걱정하지 않을만큼 빠르다는 것을 보여주는 것입니다. 내 질문을 어떻게 수정 하시겠습니까? 또한 내 대답은 경비원의 사용 또는 사용에 대한 대답을 의도하지 않습니다. 그것은 내가 믿는 OP 질문에 대한 답입니다. =) – gsamaras