C++ 컴파일러의 성숙도(?)에 대하여..
GCC 컴파일러나 Native Compiler의 플랫폼 별 (Linux, Windows, SUN Solaris, HP-UX, IBM AIX 등) 성숙도가 정리된 사이트가 있을까요? 있다면 링크나 레퍼런스 부탁드립니다 (여기서 성숙도란, 해당 컴파일러의 플랫폼 & 버전 별 C++ 관련 문법 지원 정도와 Template 문법 및 STL지원 정도, 컴파일러 관련 버그 레포팅 등)
회사에서 하는 일이 cross-platform 하에서의 시스템 소프트웨어 개발인데(지원 플랫폼은 Linux, Solaris, HP-UX, IBM-AIX, Windows 등 이고, Windows 외의 플랫폼은 Native Compiler 나 GCC 를 쓰고, GCC 는 2.96 이상의 여러 버전들을 씁니다) C++ 관련 문법들이 cross-platform 지원 중 플랫폼 별 컴파일러 버그나 성능의 문제로 사용하지 말 것이 코딩 컨벤션으로 잡혀 있습니다.
예를 들면
* 클래스의 생성자를 쓸 수 없습니다. (플랫폼에 따라 클래스의 생성자가 호출 안되는 경우가 있다는군요. C 구조체 처럼 memory 생성 뒤 initialize 함수를 명시적으로 호출해주어야 합니다.)
* 소멸자 또한 마찬가지입니다. (소멸자는, 어차피 객체 소멸 전 다른 resource 해제를 할 일이 많아서 딱히 큰 문제는 아닙니다)
* 클래스의 인스턴스를 가급적 만들면 안됩니다. (퍼포먼스 문제가 가장 크고 그 다음으로는 컴파일러 버그가 있다고 합니다. 대부분의 클래스의 멤버 함수들이 static 함수 이고, 컴파일러가 넘겨줘야 할 this -- 해당 객체에 대한 data structure의 포인터 -- 를 개발자가 직접 다 넘기는 모양새입니다)
* virtual function, operator overloading 당연히 퍼포먼스 문제로 안됩니다. (소스 코드를 보니, 전부 구조체에 함수 포인터들을 멤버로 둔뒤, 이를 어플의 initialize 관련 코드에서 전부 손으로 세팅하더군요)
* static initializer 를 사용할 수 없습니다. (역시 플랫폼에 따라 컴파일러 버그로 static initializer 를 호출 안하고 넘어가는 경우가 있다고 합니다. 간단히 말하면, singleton 의 구현이 불가능합니다. singleton 안쓰고 디자인을 개선시킨다면야 좋기야 하겠지만, 그대신 singleton 이 될 부분들이 전부 전역변수와 extern으로 나와있습니다)
* Template, STL 사용 불가 입니다. (역시 퍼포먼스 및 포팅 문제)
* Exception (성능 및 포팅 문제. goto 를 #define 으로 적절히 만든 자체 Exception Handling 을 씁니다.)
아마 메인터넌스를 오래 해온 개발자 분들이 수많은 현실 버그들에 데여서 만들고 굳어진 룰 인 것 같긴 한데.. 이 상황이 여러 플랫폼에서 컴파일이 되게끔 고려할 때의 C++ 컴파일러의 현실(?)인지, 아니면 근거 없는 미신인건지 궁금합니다.
만일 현실이라면.. 집에 있는 대부분의 C++ 책들은 걍 버리는게 공간낭비를 덜 할 것 같네요. -_-;
* 또하나 들던 생각은.. Modern C++ Design 같은 류들의 소스코드는 과연 어느 플랫폼에서 어떤 어플리케이션 돌리는 코드일까 하는 생각이..
실제 사실입니다.
좀 오래전에 작성된 mozilla "cpp 포팅 가이드"라는 문서가 있습니다.
파이어폭스를 여러 cpp 컴파일러로 다양한 플랫폼에서 컴파일하는 과정에서 부딪히게 된 문제들을 다루고 있습니다.
http://developer.mozilla.org/en/docs/C%2B%2B_Portability_Guide
이런 문제들이 발생하는 이유를 몇가지 추려보자면
1. 상대적으로 c 컴파일러 개발에 비해 cpp 컴파일러가 복잡하다.
2. cpp는 태생적으로 c의 확장 성격을 띄고 있으며 초기 문법등에서 불분명한 요소가 다분했으며 지금도 많은 변화가 이뤄지고 있다. (지금도 cpp 컴파일러는 c front인 경우가 꽤 있습니다.)
3. 각 플랫폼 회사들이 좋은 컴파일러를 만들 이유를 찾지 못했거나 여력이 없다.
결국 멀티 플래폼을 고려한다면 gcc가 최선의 선택이겠죠.
( 그럼에도 gcc도 각 플랫폼 별 지원 사항들이 약간씩 차이 납니다. )
이런 문제에 골머리가 아픈 많은 개발자들은 그냥 c로 만족하고 삽니다.
좋은 자료 감사합니다.
링크의 내용을 보니 최근에 많이 관찰했었던 소스 형태들이 보이네요. 몇몇 이해가 안갔던 코드들과 룰들의 뒷 배경이 이해가 갑니다.
한편으로는, Revision History 상으로 2001년 2월인데 6년이 지난 지금의 상황이 어떤지도 궁금해지네요. 현재 관리되고 있는 Legacy Code 는 1990년도 후반 부터 작성되었던 코드여서, 그 때 당시의 컴파일러 기준으로 위의 문제들이 똑같이 발생했으리라 생각됩니다. 그 이후 7-8년 간의 시간이 흘렀으므로 그 가운데 어느정도 개선은 있었으리라 추측되어서요.
* 다른 설탕들은 바라지도 않고.. 객체 인스턴스라도 제대로 만들 수 있었으면 한다는.. -_-;;
C++이 저렇게 컴파일이 안되나요?
그러면... Primer Plus C++ 이런 책이나 여타 나온 C++의 기법들은 다 거짓말인가요 -_-a
작성은 되나 제대로 동작은 안하는??
좀 컴파일에서 무겁게 되거나 플랫폼 별로 약/간/ 안되는 정도인줄 알았는데... 심각하네요?
Senior Engineer
퍼포먼스와 호환성은 좀 차이가 있습니다.
발제글을 잘 읽어 보시면 알겠지만 성능을 고려해 쓰지 않는 경우와 호환성 문제로 인해 쓰지 않는 경우는 다릅니다.
재밌네요...
상위 말씀하신 것중...몇가지는...C++이 아예 아닙니다. 생성자,소멸자가 안불린다? virtual function이 안된다? 맙소사. 저정도의 기능은 TI DSP환경내의 CCS 2.2 (개발 IDE 입니다...Visual Studio 비스무리합니다. 2버젼대는 대충 2000년도 초반대에 만들어졌습니다. 요즘은 3.2, 3.3을 사용합니다만 제가 참여하고있는 프로젝트의 소스가 2.2버젼기반이라서 낮은 버젼으로 사용중) 에서도 충분히 지원됩니다. 아니, 하다못해 기본적인 템플릿(부분특화!!까지) 지원됩니다.
C++컴파일러를 지원한다고 하면...일단 생성자,소멸자,가상함수는 아무리 못된;;시스템이라고 해도 지원합니다.
그리고 전역 static 객체문제는 이식성이 떨어집니다. 언제 해당 instance가 생성 완료되는지, ANSI C++ 에서도 명시되어있지않습니다. (구현이슈) 그래서 MEC++(More Effective C++)에서 보면...싱글톤을 사용할 것을 권고하고 있습니다. 예를 들어 이런식이죠.
class singleton { static A* instance() { static A; return &A; } };저렇게 쓰이는 이유는 singleton::instance()가 호출되기 전에는 static A가 instance화 되지않습니다. 첫호출시에 비로소 생성되므로, 생성 시점을 언제나 첫호출로 보장할수 있다는 점 되겠습니다.
제가 봤을때...언급하신 시스템들은 General한 목적으로 상당히 많이 쓰이는 시스템들입니다. 혹여 특정 old버젼 상용 C++ compiler를 쓰시는 것이 아니라면 대부분 Unix쪽은 GCC를 쓰실것 같습니다만...언급하신 문제들 중에 포팅으로 문제시 될만한 부분은 static, template, exception 정도가 될것 같네요. 특히 template의 경우는 나름 최신 규격이라...깊이 파고들면(Boost의 MPL정도) 지원을 못하는 경우가 많습니다. 하지만 뭐...일반적으로 쓰이는 정도의 템플릿은 왠만하믄 큰 문제는 없을겁니다. (당연히 확신은 못드립니다 ^^;;)
위에 다른 분이 링크걸어주신 포팅관련 문제점들과 MEC++의 C와의 연계 문제를 함께 보시면 좋을것 같네요. (두 부분에 겹치는 내용도 있습니다.)
기존에 사용하지말아야 된다는 부분은...그냥 추측입니다만. 아주 예전에 작성되어진 후, 아무도 그 성역을 깨지않으려고 했을 것 같다는느낌이 듭니다. 대충...직원의 90%정도는...그냥 주어진것에 만족할 뿐, 더 이상의 개선의지가 없는 경우가 많습니다. -_-a
------------------------------------------
Let`s Smart Move!!
http://kalstein.tistory.com/
그냥 잡설을
그냥 잡설을 덧붙이면...
위와같은 권고안을 뒷받침 할 수있는 증거를 보여달라고 해보세요 (그대로 말씀드리면 물론 욕먹구요 ㅋ 좀 부드럽게 돌려서~) 열에 여덟,아홉은 '그냥 그렇다' 라고 할 확율이 99.9% 에 가깝습니다.
그럼 님의 회사에 새 바람이 일기를 바라며. ^^
------------------------------------------
Let`s Smart Move!!
http://kalstein.tistory.com/
댓글 달기