728x90
반응형
728x90
반응형
728x90
반응형

http://j2doll.tistory.com/109

소스 출처 : C++ gotchas! 및 Internet


 최대한 잘라먹기(Maximal Munch)는 컴파일러(compiler)의 파싱(parsing) 처리 방법 중 한가지 입니다.

컴파일러가 입력한 구문(syntax)을 토큰(token)으로 파싱하여 형태소 분석(lexical analysis)을 하는 과정에서, 가장 긴 토큰을 중심으로 나누어 의미를 두는 과정을 의미합니다.

 [이해가 되시면 당신은 천재! 하단의 글은 보실 필요 없습니다.]


 +++++p->*mp 


 상단의 코드는 C++ 언어로 작성된 코드입니다.

 컴파일러는 해당 코드를 독자적인 처리 방법으로 파싱을 합니다.

 물론 처리 후 컴파일 성공 또는 오류를 출력합니다.


그런데 상단의 코드에서 애매모호한(ambiguous) 부분이 많습니다.


컴파일러는 ->* 을

-> 와 * 으로 해석할수 도 있고,

->* 로 볼 수도 있습니다. 

[솔직히 책에서 설정한 예제가 좋지는 않습니다.]


다음 예제는 STL 로 작성된 코드입니다. 

 list<vector<string>> loves; 


위의 코드도 애매모호합니다.

꺽쇠 괄호(angle bracket)는 이동 연산자(shift operator) >> 로 해석될 수 있기 때문입니다. 

 list< vector<string> > loves; 


위와 같이 해주면 의미가 명확해 집니다. 

 [노란색 영역은 공란(space) 입니다.]


자, 이제 문제가 해결되었습니다!!


그런데... 항상 그런 것은 아닙니다!

일부 컴파일러는 컴파일러가 알아서(take care of it) 성공으로 처리합니다. 

Visual C++ 2005 같은 경우는 컴파일이 성공합니다. [이 글의 초안은 2007년에 작성되었습니다.]

What the F..?! 이제 대충 감이 오십니까?


 최대한 잘라먹기의 현실 세계의 문제점은

 '컴파일러의 종류와 버전(version)'마다

 최대한 잘라먹기를 처리하는 방법의 차이가 다르다는 것입니다!!

상단의 코드를  gcc 3.4.2 로 컴파일(Compile) 및 빌딩(Building)을 해봅시다. 
gcc 3.4.2를 포함하고 있는 Dev-C++ 를 써서 컴파일을 하면

역시 오류가 발생합니다.

사용자 삽입 이미지


그 외에 Dinkumware 에서 제공해주는 웹에서 해보는 컴파일을 해봅시다.

  http://www.dinkumware.com/exam/

  [참고로 이글의 초안은 2007년에 작성되었으며, 현재 exam 페이지는 폐쇄되었습니다]

  MINGW/GCC 에서 컴파일하면, 

sourceFile.cpp: In 

   function `int main(int, char**)':
sourceFile.cpp:9: `>>' 
   should be `> >' in template class name
sourceFile.cpp:12:2: warning: no newline at end of file

역시 오류가 발생합니다.

다음은 예제 코드를 C99 에서 컴파일하는 경우입니다.

 "sourceFile.c", line 9: error: 

          space required between adjacent ">" delimiters of nested template
          argument lists (">>" is the right shift operator)
      list<vector<string>> loves;
                        ^

"sourceFile.c", line 12: warning: 
          last line of file ends without a newline
  }
   ^

역시 오류입니다. (참고로 Visual C++6(STL98) 에서도 오류입니다)


[하지만, 필자는 최근에 g++ 4.8과 g++ 7.3으로 컴파일 해본 결과, 모두 컴파일에 성공하였습니다.]


이 정도 되면 코드의 버그를 정의하기 애매합니다. 

이것이 오류이다!!! 라고 딱 집어 말하기도 애매한 것이지요.


수년전 컴파일러 사용시 버그(bug)로 판명된 코드가 

최신 컴파일러에서는 버그가 아닌 것이 됩니다!!


하지만 이건 컴파일러 개발사 만의 문제는 아닙니다.


일부 언어는 코드를 작성시 매우 엄격한 구문을 강요합니다.

탭(tab), 공란(space), 줄바꿈(CR) 등에 대한 정의가 명확한 언어도 있으며, 애매모호한 언어도 있습니다. 

일례로, 파이썬(python)의 탭과 공란은 함수 및 루틴(routine) 정의에서 필수적이기에 자바(java)에서의 탭과는 비교할 수 없는 점이 있습니다.


 비야네 스트롭의 책으로 C++를 학습한 이들은 띄어쓰기 등을 문맥에서 읽어 낼수는 없습니다. 

 C++ 배우는 이들이나 컴파일러 개발사만을 매도하기는 문제가 있습니다. 

 [개발의 고수(guru)들은 상단의 이슈 사항을 다양한 경험을 살려서 알아서~~ 피해 갑니다. 

 하지만 모두가 고수는 아닙니다. 또한 문제의 해결은 일반적인 경우를 고려하여야 합니다.]


 끝으로 한마디 덭붙이면,

 구형 컴파일러에서 오류를 내는 방식이 반드시 잘못된 것은 아니라는 점입니다.

 애매모호한 코드(ambiguous code)를 오류 처리하는 것이 과연 잘못일까요?


 현실 세계에는 맞춤법을 무시한 다양한 관용어(Idiom)를 사용합니다. 

 언어는 변화하는 것이기에 맞춤법을 준용하는 것이 옳을 수도 있으며,

 유연한 관용어구를 사용하는 것이 옳을 수도 있습니다. 


 표준(standard)을 준용했다면 처리 방법에 대한 정답은 없습니다.

 표준이 설명해 주지 못한 부분은 표준 위원회(Committee)가 노력할 일이겠지요.


 어쨌든 이런 경우도 알아 두시면  

 도움이 되시리라 믿습니다. ㅅ-ㅅ


728x90
반응형

'C C++' 카테고리의 다른 글

현재 윈도우즈 버전 얻기 예제  (0) 2007.05.19
C++ 상수 포인터  (0) 2007.05.17
TTOF2() 함수  (0) 2007.05.09
CMainFrame IDR_MAINFRAME 확장자 연결 문자열  (0) 2007.04.26
GetProcAddress 과 Unicode  (0) 2007.04.14

+ Recent posts