C 및 C ++ 컴파일러가 오류를 복구하고 구문 분석을 계속 시도하는 이유를 이해하지 못했습니다. 거의 항상, 첫 번째 오류는 첫 번째 오류가 수정 되 자마자 사라지는 가짜 오류 스트림을 생성합니다. 수년간의 경험을 쌓은 후, 나는 모든 파일 중 첫 번째 파일을 제외한 모든 오류를 보는 것을 중단했습니다. 컴파일러를 다시 실행 한 다음 더 이상 오류가 없을 때까지 다시 수행합니다. 일반적인 관행입니까?
답변:
때때로 오류는 관련이 없습니다. 오류 목록을보고 일련의 관련 오류의 근본 원인을 수정 한 다음 관련 되지 않은 다음 오류를 수정하는 것이 더 쉽다는 것을 알았습니다 . 프로젝트가 크고 빌드하는 데 시간이 걸리면이 방법으로 작업하는 것이 첫 번째 오류를 수정하고 다시 컴파일하고 반복하는 것보다 덜 실망 스럽습니다 ...
예, 컴파일러를 사용하여 리팩토링하는 데 도움이되지 않는 한 동일한 작업을 수행합니다.이 경우 전체 오류 목록을 좋아합니다. :)
예-또는 적어도 나는 탈지합니다. 오류가 관련되어 있는지 (보통 줄 번호를 보는 것으로 충분 함) 알아내는 것이 매우 쉽고, 한 번에 모두 수정 한 다음 다시 컴파일하는 것을 좋아합니다.
1 cpp 컴파일이 매우 긴 경우에만이 작업을 수행합니다 (첫 번째 오류를 지나서 오류를 읽습니다). 또는 사용할 수 없습니다. 그런 다음 컴파일러 오류에서 식별 할 수있는 모든 것을 첫 번째 오류와 관련이없는 것으로 수정했는지 확인하고 싶습니다.
cpp 파일을 단독으로 컴파일 할 수 있고 1 초 이내에 (또는 컴파일을 시작하기 전에 "지능형"포인팅 오류가있는 경우) 대부분의 시간을 할 필요는 없습니다.
나는 현재 하나의 cpp 만 컴파일 할 수없는 프로젝트에서 일하고 있습니다 (그리고 빌드 시스템에 손을 대지 않아도 O__o를 변경할 수 없습니다). 일부 cpp 파일은 컴파일하는 데 10 분 이상 걸릴 수 있습니다 ( 그것을 줄이기 위해 많은 노력을 기울인 후에도 원래 컴파일 시간의 50 %로 줄였습니다 ...).
이런 종류의 매우 긴 컴파일 설정에서, 당신은 "build"를 누르기 전에 많은 것을 먼저 생각하는 경향이 있습니다 ... 그리고 심지어 나중에 생각하기도합니다. 아마 컴파일러보다 버그를 발견하기 전에, 그것들보다 정신적으로 빨리 얻는 것이 더 빠를 수도 있습니다. .
당신이하는 것처럼하는 것이 일반적입니다. 나는 보통 인턴 또는 초보자 프로그래머에게 오류의 수에 압도되어 첫 번째 오류를 제외한 거의 모든 오류를 무시하도록 지시합니다. 수정해야 할 실제 오류 일 가능성이 높으며 이전 오류로 인한 잘못된 팬텀 오류가 아닙니다. 일부 (대부분?) 컴파일러에는 이러한 이유로 첫 번째 오류 후에 컴파일을 중지하는 옵션이 있습니다. 일반적으로 빌드 시스템은 오류가있는 첫 번째 파일 이후에 중지되도록 구성 할 수 있습니다.
그러나 오류를 감지 한 후에도 계속 컴파일해야하는 이유가 있습니다. 예를 들어, 오류가있는 파일 수를 계산하거나 포함 된 헤더 파일이 둘 이상의 파일에서 오류를 발생시키는 지 확인할 수 있습니다.