programing

컴파일러가 세미콜론을 찾을 수 없는 이유는 무엇입니까?

kingscode 2022. 9. 1. 23:40
반응형

컴파일러가 세미콜론을 찾을 수 없는 이유는 무엇입니까?

다음과 같은 간단한 프로그램이 있습니다.

#include <stdio.h>

struct S
{
    int i;
};

void swap(struct S *a, struct S *b)
{
    struct S temp;
    temp = *a    /* Oops, missing a semicolon here... */
    *a = *b;
    *b = temp;
}

int main(void)
{
    struct S a = { 1 };
    struct S b = { 2 };

    swap(&a, &b);
}

를 들어 ideone.com에서 볼 수 있듯이 다음과 같은 오류가 발생합니다.

prog.c: In function 'swap':
prog.c:12:5: error: invalid operands to binary * (have 'struct S' and 'struct S *')
     *a = *b;
     ^

컴파일러가 세미콜론을 검출하지 못하는 이유는 무엇입니까?


주의: 이 질문과 답변은 이 질문에서 비롯되었습니다.와 유사한 질문도 있습니다만, C언어의 자유형식 기능에 대해서는, 이것과 관련된 에러의 원인이 되고 있는 것은 찾을 수 없었습니다.

C는 자유형 언어입니다.즉, 여러 가지 방법으로 포맷할 수 있으며 여전히 법적 프로그램이 될 것입니다.

예를 들어 다음과 같은 문장이 있습니다.

a = b * c;

라고 쓸 수 있다

a=b*c;

또는 같은

a
=
b
*
c
;

그래서 컴파일러가 이 행을 봤을 때

temp = *a
*a = *b;

그것은 그것이 의미한다고 생각한다.

temp = *a * a = *b;

이는 물론 유효한 표현이 아니며 세미콜론이 없는 대신 컴파일러가 이에 대해 불만을 제기합니다.무효인 이유는a에, 「」를 참조해 주세요.*a * a는 구조 인스턴스즉, 구조 인스턴스)를 증식하려고 .*a ) ( )가 .a를 참조해 주세요.

컴파일러는 누락된 세미콜론을 검출할 수 없지만 전혀 관련이 없는 오류를 잘못된 행에 보고합니다.에러가 보고되는 행은 아무리 봐도 에러가 발생하지 않기 때문에, 주의해 주세요.이러한 문제는 이전 행이 정상인지, 오류가 없는지 확인해야 하는 경우가 있습니다.

오류를 찾기 위해 다른 파일을 찾아야 할 수도 있습니다.예를 들어 헤더 파일이 헤더 파일에서 마지막으로 정의한 구조물을 세미콜론이 존재하지 않는 경우 오류는 헤더파일이 아니라 헤더파일이 포함된 파일에 있습니다.

게다가 경우에 따라서는, 2개(또는 그 이상)의 헤더 파일이 포함되어 있는 경우, 첫 번째 헤더 파일에 불완전한 선언이 포함되어 있는 경우는, 대부분의 경우, 구문 에러가 두 번째 헤더 파일에 표시됩니다.


와 관련된 것이 후속 조치 오류의 개념입니다.실제로는 세미콜론이 없기 때문에 발생하는 오류는 여러 오류로 보고됩니다.따라서 첫 번째 오류를 수정하면 여러 오류가 사라질 수 있으므로 오류를 수정할 때는 처음부터 다시 시작하는 것이 중요합니다.

물론 이로 인해 한 번에 하나의 오류가 수정되고 대규모 프로젝트에서는 번거로운 재컴파일이 빈번하게 발생합니다.이러한 폴로업 에러를 인식하는 것은 경험이 수반되는 것으로, 몇 번인가 확인하면, 재컴파일 마다 실제의 에러를 찾아내, 복수의 에러를 수정하는 것이 용이하게 됩니다.

컴파일러가 세미콜론을 검출하지 못하는 이유는 무엇입니까?

기억해야 할 세 가지가 있습니다.

  1. C의 행 끝은 일반적인 공백입니다.
  2. *C는 단항 연산자 및 이진 연산자일 수 있습니다.단항 연산자로는 "참조 해제"를 의미하고, 이진 연산자로는 "다중화"를 의미합니다.
  3. 단항 연산자와 이진 연산자의 차이는 해당 연산자가 보이는 컨텍스트에 따라 결정됩니다.

이 두 가지 사실의 결과는 우리가 해석할 때이다.

 temp = *a    /* Oops, missing a semicolon here... */
 *a = *b;

와 마지막 '마지막'*되지만 두 '단항'으로 해석됩니다.*을 사용하다구문의 관점에서 이것은 정상으로 보입니다.

컴파일러가 오퍼랜드유형의 컨텍스트에서 연산자를 해석하려고 할 때 비로소 오류가 발생합니다.

위의 몇 가지 좋은 답변이지만, 자세히 설명하겠습니다.

temp = *a *a = *b;

은 사실 '아예'의 입니다.x = y = z;x ★★★★★★★★★★★★★★★★★」yz.

있는 말은 슨슨 what what what what what what what what what what whatthe contents of address (a times a) become equal to the contents of b, as does temp.

로 말하면, 요,,,*a *a = <any integer value>는 유효한 스테이트먼트입니다.한 바와 같이 첫 '는 '''입니다.*는 포인터를 참조하지만 두 번째 포인터는 두 개의 값을 곱합니다.

대부분의 컴파일러는 소스 파일을 순서대로 해석하여 문제가 있음을 발견한 행을 보고합니다.C 프로그램의 처음 12행은 유효한(오류가 없는) C 프로그램의 시작일 수 있습니다.프로그램의 처음 13행은 사용할 수 없습니다.컴파일러에 따라서는 에러가 아닌 에러의 위치를 기록해 두는 것도 있습니다.대부분의 경우, 에러는 코드의 후반부에 트리거 되지 않지만, 다른 것과 조합하면 무효가 되는 경우가 있습니다.예를 들어 다음과 같습니다.

int foo;
...
float foo;

" " "int foo;선언도 마찬가지입니다.float foo;일부 컴파일러는 첫 번째 선언이 나온 행 번호를 기록하고 그 행에 정보 메시지를 연관시켜 프로그래머가 초기 정의가 실제로 잘못된 경우를 식별하는 데 도움을 줄 수 있습니다.는, 행 .do는, 관련지어져 있는 경우에 보고할 수 있습니다.while가 올바르게 표시되지 않습니다.다만, 에러가 검출된 행의 바로 앞에 문제의 장소가 있을 가능성이 있는 경우는, 통상, 컴파일러는 그 위치에 관한 리포트를 추가하지 않습니다.

폴란드 영화 'Nothing Funning'이 있어요.여기 컴파일러 개발자들이 무모하게 세미콜론이 누락되었다고 선언하는 것을 조금 부끄러워하는 이유를 정확히 보여주는 장면에서 관련 대화를 발췌한 것이 있다.

디렉터:"이거"라니 무슨 말이야?이 물체가 내 시야에 있다는 거야?손가락으로 가리켜봐 내가 꿈을 꾸고 있다고 믿고 싶거든

아담: 여기, 여기(포인트)입니다.

디렉터:이거? 이게 뭐야?

아담: 무슨 뜻이야?숲이에요.

대체 왜 숲이 필요한지 말해줄래?

Adam: 왜 "피나는 지옥"이야?여기, 시나리오에 숲이라고 쓰여 있는데...

디렉터:시나리오에서요?이 시나리오에서 찾아주세요.

아담: 여기: (읽기) "길 꼭대기에 다다랐을 때, 그들 앞에 숲이 나타났다."

디렉터:페이지를 넘기다.

아, 젠장...

읽어주세요.

그들 앞에 숲이 나타났다...비석의.

비석의 숲이 아니라 숲을 의미한다고 미리 말하기는 쉽지 않아요

언급URL : https://stackoverflow.com/questions/40135392/why-doesnt-the-compiler-report-a-missing-semicolon

반응형