몇주 전쯤에 커런트에 gcc 3.4가 들어오면서, gcc 마이너 버전이 올라갈 때마다 있는 행사인 포트 대량 깨짐이 일어났습니다. gcc가 점점 더 문법이 빡빡해 지는 것 같군요.. 3.0에서 3.1로 올라갈 때는 정말 엄청났던 기억이 납니다 흐흐; (2.95에서 3.0으로는 빌드 고치는 PR 만 수십개를 올려서 한달만에 포트 커미터가 된 사람이 여럿 나올 정도였긴 하지만;; )
이번에 제 포트 중에서는 graphics/py-gdchart 와 archivers/py-lzma 가 깨졌다고 kris가 벤또를 통해서 알려왔는데, py-gdchart는 switch문 안에서 default뒤에 스테이트먼트 없이 그냥 끝내는 바람에 에러가 났던 것이고.. (이게 왜 그동안은 컴파일 됐던 것이지 흐흐;;) py-lzma의 경우에는 무지 신기한 에러라서 고치긴 했는데 왜 이렇게 하면 고쳐지는지 이해도 못 하고 있습니다. (사실은 C++을 할 줄 몰라서;;)
그게 어떤거냐면~ 소스가 대충 이렇게 되어있습니다.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
template <int aNumMoveBits> class CBitModel { public: UINT32 Probability; void UpdateModel(UINT32 symbol) { (중략) Probability -= (Probability) >> aNumMoveBits; // <= *여기1* } }; template <int aNumMoveBits> class CBitEncoder: public CBitModel<aNumMoveBits> { public: void Encode(CEncoder *encoder, UINT32 symbol) { encoder->EncodeBit(Probability, kNumBitModelTotalBits, symbol); UpdateModel(symbol); // <= *여기2* } (후략) |
정말 이상하게도 *여기1* 부분에서 Probability가 멤버임에도 불구하고 그냥 Probability라고 쓰면 undefined라고 에러가 납니다. 그래서 this->Probability로 고치는 걸로 해결했는데.. –;; 왜 그러면 또 되는지~ 흐흐.. 그리고 *여기2* 부분에서도 UpdateModel이 부모 클래스인 CBitModel의 메쏘드인데도 또 undefined라고 그래서.. 그것도 this->UpdateModel로.. 우엑~ gcc 3.4의 미스터리인지.. 원래 템플릿을 쓰면 그런건지 잘 모르겠네요 *.*
gcc 3.x로 오면서 c++쪽의 문법이 대단히 빡빡해진인 익히 알려진 사실립니다. 소수의 전체를 보지 않아서 뭐라 말씀은 못드리겠습니다만..(사실 고수가 더 많은..-.-)
this-> 로 들어가는 식의 문법이 사실은 정석인거지요.
더 심한경우도 많았습니다. 아시다시피 gcc 3.x로 오면서 예전에는 관용적으로 그러려니..하고 넘어가던것들이 안되는 현상이랄까.. string관련 class들도 사용시에 걍 사용하면 되었던것들이 strings.aaa (이런식이던가 기억이 가물…) 이런식으로 처리되는.. 그러니깐
“정확한 명시”가 포인트가 된거죠…
뭐 물론 다 아시는거겠지만.. 걍 함 얘기만 해봅니다요..-.-;
“C++ Templates: The Complete Guide” 이 책에 보면 설명이 나와있긴 하던데, 결론은 위와 같은 경우에 꼭 this나 Base<T>를 사용해서 정확하게 명시 해라. 라더군.
‘ㅇ’ ..전 요즘 공각기동대 S.A.C 가 생각나더라는 ( —)..