바로 그런 점에서 저와는 생각이 다르다고 말씀드린 건데요. ^^

권고된 표준안을 100% 지키는 C/C++ 컴파일러는 과거에도 없었고 지금도 없습니다.
앞으로 나올지는 모르겠습니다만... 전 별로 의미없는 일이라고 생각하는 겁니다.

개발자들이 표준에 대해 몰두하는 것은 89년 ANSI C89가 나왔을 때의 여파 때문입니다.
1989년의 C89 발표가 엄청난 이슈가 되었던 것은, "표준"이라는 개념이 정말 중요하기
때문이 아니었습니다. 70년대부터 80년대까지 C언어가 대부분의 플랫폼에 급속하게 퍼졌는데,
그 컴파일러들 사이에 호환성이 전혀 없어서 개발자들이 여러 플랫폼 사이에서 골머리를 썩이고
있었기 때문입니다.

C89의 발표로 무분별하게 스펙을 만들어대던 난장판은 일단락이 되었습니다.
C89 이후로는, C++98의 발표때도 C99의 발표때도 C89의 발표 때처럼 큰 영향은 없었습니다.

사실 그럴 필요가 없었습니다.
C++98의 경우엔 스트로스트럽이 직접 C++의 표준을 정리해나가고 있었기 때문이고,
C99의 경우엔 C89에서 이미 혼란스러운 스펙들이 다 정리된 후였기 때문에 C89와 같은
"혼란의 표준화"가 목적이 아니라 "언어의 개선"이 목적이었기 때문입니다.

더 구체적으로 설명을 드리면..
89년 이후의 "표준화" 작업이란, 컴파일러 벤더들이 추가해놓은 비표준 스펙들이 적어도
일반적으로 정착되기 전인 상태에서 표준화기구에 제안을 하고 있지만,
70년대 말에서 89년까지 C89를 제정하던 당시의 상황은, 서로 호환이 전혀 되지 않는 비표준
스펙들을 이미 한참 오래써왔고 각각의 플랫폼에서 제각기 "한칼" 하고 있던 상황이었단 말이죠.
요즘의 표준화 작업에서 제안된 어떤 스펙이 받아들여지지 않더라도 별 큰일이 아니지만,
당시에는 각 컴파일러 벤더들의 목숨을 걸고 있던 엄청난 작업이었습니다.
그래서 성공적으로 ANSI C89 표준이 발표된 것에 대해 개발자들이 열광할 수 밖에 없었습니다.

그러니까, C89는 단지 처음이어서 의미가 더 있는 것이 아니라, 당시의 시장 상황에 의해
C++98이나 C99와는 비교도 안되는 엄청나게 중요한 표준이었습니다.
하지만 C89의 경험으로 인해, C/C++ 개발자들 사이에서 "표준"이라는 말은 하나의 맹신으로 남게 되었습니다.


91년이었던가 92년에, 몇달동안 터보C로 작성된 소스를 마이크로소프트C로 포팅하는 아르바이트를
한 적이 있었습니다. 꽤 많은 양의 소스였는데..
터보C 2.0을 쓰고 있었으니까, ANSI 표준안이 나오기 전의 버전이었습니다.
ANSI C 표준안은 1989년에 나왔는데 터보 C 2.0은 1988년에 나왔으니까요.
그리고 확실히 기억은 안나지만 마이크로소프트C의 버전도 표준안 이전의 버전이었던 거 같습니다.

두개의 C 컴파일러가 다 표준안을 확실히 지키지 않는 상황이었음에도, 그 포팅 작업에서
최대의 난점은 언어 스펙의 차이가 아니라 라이브러리의 차이였습니다.
그래픽 모드 함수들, 인터럽트 관련 함수들 등등등, 공통 함수보다 벤더 의존적인 함수가 훨씬
많았습니다. 같은 역할을 하는 함수가 있기라도 하면 다행이지만, 그래픽 모드는 당시에 터보 C의
BGI가 훨씬 앞서있었기 때문에 MS C로 포팅하는 데 정말 애를 먹었었습니다.

당시에 그나마 표준이라고 불리던(ANSI 표준안이 나오기 전 버전이니까 확실한 표준도 아니었지만)
C 함수는 백개가 약간 넘는 정도였는데, 터보C 레퍼런스에 나오는 함수가 415개였으니, 당연히
호환이 안됩니다.

이식성을 따지는 자체가 말이 안되는 상황이었습니다.
C/C++ 언어의 특성상 소스에서 아이덴티파이어들 중 키워드에 비해 함수가 많을 수밖에 없는데,
그 함수들 중 3/4 가까이가 비표준 함수니까요.

C++로 오면서 상황은 더 심각해졌습니다. 특히 윈도우에서는요.
MFC, OWL, VCL은 함수들 뿐 아니라 서로 전혀 구조조차도 다릅니다.
MFC로 작성된 소스를 C++Builder로 포팅하려면(그대로 임포트하는 경우를 제외하고)
언어의 호환성은 사실 거의 완전히 무시할 정도가 됩니다.
물론 거꾸로도 마찬가집니다. 소스의 전반적인 구조조차도 달라지게 됩니다.

리눅스 등 유닉스 환경에서는 상황이라고 특별히 더 낫지도 않습니다.
90년대 초에 POSIX 표준이 발표되었는데, 유력한 대형 벤더 몇개는 아직도 POSIX를 따르지 않습니다.
그리고 POSIX를 따르는 유닉스들에서조차, "POSIX를 따르는 기술"을 거론할 정도로,
아직도 POSIX가 일반적이지 않습니다.

STL이 유일한 구원일 수 있습니다. 하지만 STL이 "표준"이라는 타이틀을 달고 있음에도
아직 STL은 C++ 프로그래머들 사이에 충분히 일반적이지 않습니다.
또 STL을 사용한다고 하더라도, STL 자체에는 GUI 환경을 지원하는 부분은 없습니다.
역시 GUI 환경을 위해서는 플랫폼에 의존적이 될 수밖에 없습니다.

C나 C++에서의 소스 수준 호환성, 이식성이라고 하는 것은, 대단히 유사한 두 플랫폼 사이에서나
혹은 STL과 같이 라이브러리 수준과 같이, 그 거창한 개념에 비해서 실제로는 아주 제한적으로만
가능한 것입니다.

윈도우의 소켓은 유닉스의 버클리 소켓을 차용한 것이지만, 윈도우에 추가된 메시지기반 소켓
처리라든지 IOCP 등 여러 새로운 개념이 추가되면서, 윈도우 소스를 유닉스로 포팅하는 것은
아예 호환성을 거론하기가 어렵습니다. 물론 처음부터 포팅을 고려해서 만들었다면 얘기가 다를 수
있지만, 그런 경우 각 환경에서 최적화된 성능을 내지 못하죠.
IOCP와 일반 소켓의 성능 차이를 아는 이상 포팅을 위해 IOCP의 성능을 포기하기는 쉽지 않을 겁니다.

이런 면에서 볼랜드의 C++Builder-Kylix와 Delphi-Kylix는 상당히 뛰어난 크로스플랫폼의 예입니다.
물론 볼랜드의 정책상 모든 플랫폼을 지원하지도 않고 또 개발자가 CLX 외에 맘대로 플랫폼 의존적인
코드를 써버리면 그만이긴 하지만요.
그래도, 제가 지금까지 C/C++ 환경에서 본 것들 중에선 포팅을 고려한 가장! 현실적인 대안입니다.

참고로.. 볼랜드커뮤니티에 표준에 대한 제 생각과 비슷한 글이 있더군요.
http://community.borland.com/article/0,1410,10076,00.html


먼저번 글에서도 썼습니다만, 표준단체에서 표준을 발표한다고 그게 표준이 되는 것은 아닙니다.
개발자들이 안쓰면 그걸로 사장된 표준이 됩니다. IETF에서 열심히 제정한 RFC 중에도
거의 천여개의 RFC가 개발자들에게 거의 관심을 받지 못하고 썩어가고 있습니다.

ISO C99의 운명도 비슷해보입니다.
gnu와 bsd같은 몇개 비영리 단체에서는 열심히 C99를 지원하려고 계속 업그레이드를 계속 하고
있지만, 실제로 시장을 지배하는 C++ 컴파일러 대형 벤더들은 거의 관심을 두지 않고 있습니다.

사실 C의 창시자인 데니스 리치는 위원회의 요청에도 불구하고 표준위원회에 참여하지 않았고,
C99 발표 이후 인터뷰 기사를 봐도 C99에 대해 부정적으로 생각하는 것이 틀림없습니다.
그리고 C99가 발표되었는데도 K&R도 개정하지 않았습니다. 아직도 C89 기준의 2nd 에디션이 최신버전이죠.
그래서 대다수의 C 개발자들이 C99의 존재조차도 모르고 있구요.

참고로, 열심히 C99를 구현중인 gcc도 아직 C99를 완벽하게 지원하지는 못하고 있습니다.
http://gcc.gnu.org/c99status.html

사실, 볼랜드의 경우에도 C++Builder 7 관련 설문조사에서 C99 호환성의 중요도를 묻는 항목을
포함시킨 것을 보면, 볼랜드도 C99를 완전히 무시하지는 않고 있는 것 같습니다.
http://www.borlandforum.com/borland_bcb_survey2002/
하지만 적어도 적극적으로 채용할 계획은 아닌 것은 분명하죠.


제가 Daniel님과 표준에 대해 시각이 다르다고 한 것은...
!= 대신 not_eq를 쓸 수 있느냐 없느냐 하는 문제에 집착하시는 것 같아서였습니다.
유럽어권의 사람들이 아니라면 # 대신에 %:을 쓸 사람은 아주 특이한 사람이 아닌 한 없을 것이고,
표준으로 추가되었다고 수년이상씩 사용해온 || 대신 or를 쓸 사람도 없을 겁니다.

그리고 이 ISO646 표준 자체도 유니코드가 보급되면서 사장되어가고 있습니다.
얼마 안있어 유럽어권에서조차 대체표기법을 쓸 사람은 없어질 겁니다.
(그들도 웹이나 책을 통해 절대다수의 개발자들이 not_eq가 아닌 !=를 쓴다는 걸 알테니까요)


볼랜드의 ANSI/ISO C++ 지원 관련 문구에 대해서는...
그 자료가 기술 자료가 아닌 마케팅 자료라는 것을 고려해보세요.
C++Builder가 cgwin같은 gcc계열이나, 인텔 C++과 같은 마이너 C++과 경쟁할 필요가 있습니까.
당근 오직 비주얼C++만을 타겟으로 씌여진 문구입니다.

그럼...

p.s.
저도 논쟁하려고 쓰는 글은 아닙니다.
하지만, 제 생각에는 대부분의 개발자들에게는 중요하지 않을 것으로 생각되는 특이한
새로운 표준의 문제로, 그 내용의 실제 가치 이상으로 다른 포럼 분들이 혼란스럽지 않을까 해서
써봅니다. ^^



Daniel 님이 쓰신 글 :
: 요즘은 Effective C++, Effective STL을 보고 있습니다.
: 그러면서 C++ 표준안도 보게 되고, 관련 문서들도 보고 있죠.
: 그러면서 제가 알고 있던 C++에 대한 것이 상당히 피상적이었구나
: 하는 것도 많이 느꼈고요.
:
: 다만 한 가지 의문이 생겼던 것이, C++빌더의 경우에 VCL 지원을 위해서
: 자체적으로 C++ 표준안과는 다르게 언어를 확장한 부분이 많이 있죠.
: 근데, 빌더 홍보에 보면 (볼랜드 코리아 홈페이지에서)
: "볼랜드 C++Builder 컴파일러는 RTL과 STL을 포함한 최신 ANSI/ISO C++ 언어를 지원합니다."
: 라고 홍보를 하고 있죠.
: C의 경우에는 1989년 이후에, 1990, 1999년에 새로 표준안에 갱신되었지만,
: C++의 경우에는 1998년 표준안이 처음 표준안이죠.
: C/C++ Users Journal에 따르면 빌더가 표준안을 가장 많이 지원하는
: 컴파일러가 아니라는 점이죠.
: 1998년 C++ 표준안에서도 지원하지 못하는 부분도 있고, VCL 지원 때문에
: 충돌하는 부분도 있는거죠.
:
: 그냥 맹목적으로 "C++ 빌더는 표준 지원 하고 있어"라고 아는 것보다,
: 좀 더 언어적인 특징도 알아가야 한다는 거죠.
: 1999년 C 표준안에 따르면 C에서도 // 코멘트를 지원하도록 되어있죠.
: C++ 책마다 나오는 C에서는 /* */ 코멘트만 가능하고, C++에서만 // 코멘트가
: 가능하다는 것도 C 표준안에 대한 컴파일러 지원이 안되는 것이지
: C 언어의 정의에서 불가능한 것이 아니라는 것이죠.
:
: 제 요지는 "C++빌더도 컴파일러(툴)의 하나일 뿐이다.
: 따라서 먼저 언어에 대해서 좀 더 깊이있게 공부하자"는 것입니다.
: 특히 C++ 소스의 포팅의 경우에는 무척 중요한 문제겠죠.
:
:
: 박지훈.임프 님이 쓰신 글 :
: : 김재구님께서 컴파일러 옵션을 찾아서 알려주셨네요.
: : 저도 거기까진 잘 몰랐습니다.
: : bcc32.exe 안에 그런 새 키워드들이 들어있어서 짐작은 했는데 확증을 못잡아서리...
: :
: : 그러나저러나...
: : Daniel님과 저는 표준에 대해 시각이 좀 다른 것 같습니다.
: : 제가 보기엔, 정말로 중요한 것은, 표준단체에서 발표하는 표준안을 따르느냐 아니냐가 아니라,
: : 실질적으로 개발자들이 사용하는 코드가 이기종 컴파일러들 사이에 호환이 되느냐 아니냐입니다.
: : 그래서 헤더파일을 인클루드하면 된다, 정도로 말씀을 드린 거구요.
: :
: : 또, ISO이든 ANSI이든 IEEE이든 IETF이든, 이들 단체에서 발표하는 표준안은 엄격하게 말하면
: : "표준권고안"이지 실질적인 표준안이 될 수 없다고 생각하고 있습니다.
: : IT 업계에서 실질적인 표준은 업계의 대다수가 따라야만 가능한거죠.
: : 그리고 그게 표준안의 목적이기도 하구요.
: :
: : 비슷한 예로, ISO C99보다 ANSI C89가 실질적인 업계의 표준으로 인정받고 있는 것도 그렇고요.
: : 일반적으로 C 표준안을 ANSI C라고 하지 ISO C라고 하지는 않잖습니까.
: :
: : 표준이 그토록 중요했던 시기는 1989년에 ANSI C 표준안이 발표됨으로써 지나갔다고 봅니다.
: : 그전까지는 개발자들이 많이 사용하던 코드들이 수없이 호환이 안되었으니까요.
: : C++의 경우엔 표준화 이전에도 C의 표준화과정에 있었던 그런 대란은 없었죠.
: :
: : 단, 비주얼 C++은 별개의 문제죠.
: : 개발자들이 실제로 많이 사용하는 코드가 호환이 안되니...
: :
: : 기럼...
: :
: :
: : Daniel 님이 쓰신 글 :
: : : iso646.h를 include하면 macro처럼 처리되는거고,
: : : 실제 ISO/IEC 14882-1998 : Programming Language C++ 표준안에서는
: : : not_eq 같은 대체표기 token이 내장 keyword라는거죠.
: : : 가령 C++ Builder에서는 iso646.h를 include하지 않으면
: : : not_eq 같은 것을 변수명으로 사용할 수 있지만,
: : : C++ 표준안에 따르면 이것들은 keyword라서 변수명으로 사용할 수 없잖아요.
: : : 현재 GCC 3.2랑 CodeWarrior Professional 7.0 for Windows에서는
: : : 헤더 파일이 필요없이 키워드로 처리가 됩니다.
: : : 빌더에 포함되어 있는 C++ 컴파일러도 더 업데이트가 필요해 보이네요.
: : :
: :