“VC++ 6.0을 쓰지 말아야하는 이유(http://minjang.egloos.com/1783328)” 라는 글을 읽고나서도 나는 별로 VC++ 6를 버리고 싶은 생각이 들지 않는다.
난 VC++ 6가 더 손에 착착 붙으니까.
익숙하지 않은 툴을 쓸 때의 그 느낌은 몸에 맞지 않는 옷을 입은 것처럼 코딩 작업을 매우 불편하게 한다. 물론 그 이후 버전에 익숙하지 않은 것은 내 천성적인 게으름 탓일 수도 있을거다. 흐흐흐..
그러나 MFC Application을 만들 때 굳이 VC.NET 이후 버전을 써야 할 이유를 느끼지 못한 것도 한 이유다. 그렇다고 그 이후 버전을 써야만 만들 수 있는 프로그램을 만드는 것도 아니었기 때문에.. 굳이 새버전이라는 이유로 내 손에 익은 단축키와 툴들을 버리고 굳이 옮기고 싶은 마음은 들지 않는다.
게다가, “VC++ 6.0을 쓰지 말아야하는 이유” 에서 쓰고 있는 이유들, 대부분이 아직 잘 와닿지 않는다.
“1. 보다 안전한 프로그래밍”에서의 _s버전의 함수를 쓰라는 건 나보고 특정 플랫폼의 함수에 종속되란 말로 들리고, 특히나 strcpy 같은 함수를 잘 사용하지 않는 나로서는 특별히 신경쓰이지 않는다. strcpy의 버퍼오버 플로우 같은 문제는 해묵은 문제이고 이와 관련된 이야기는 많이 들은 문제 아닌가?;
“2. 유니코드 프로그래밍” 같은 문제는 사실 프로그래머의 문제지 툴의 문제가 아니라고 생각한다.
“3. 보다 뛰어난 인텔리센스”는 VC++ 6의 인텔리센스 기능에도 만족해 했던 나로서 별로..;; Visual Assist를 써도 좋고..
“4. STL의 (거의) 완벽한 지원” 의 이유는 좀 써볼만하다고 생각하긴 한다.
“5. 뛰어난 IDE 매크로 사용”은 별다른 매크로를 사용하지 않아서인지도 모르겠다. 글에 나왔던 .cpp와 .h를 연결해주는 매크로 같은건 VC++ 6에서도 만들어쓴다. 나 같은 경우는 매크로를 쓰다가 Wndtabs에 아예 내장기능으로 들어가 있는 걸 보고 그 기능을 사용하는 중이다.
“6. 더 훌륭해진 컴파일러”는 약간 수긍. 그러나 더 빠른 컴파일러가 필요할 정도로 크리티컬한 상황을 MFC App.를 짜면서는 별로 느껴보지 못했다. 빠른 컴파일러가 필요하다면 인텔 컴파일러가 최고 아닐까?
“7. 더 괜찮아진 IDE” 는 개인차일 수 있으나, 난 VC++ 6의 IDE가 더 맘에 든다. 예전, C++ Builder의 IDE가 나중에 VC.NET의 인터페이스와 비슷해진 걸 써보고, “으.. 난 전꺼가 더 좋은데…” 한탄했던 기억이.. 게다가 클래스 위저드의 기능을 사용할 수 있다고 하나, “클래스 위저드를 사용하는 것”과 “클래스 위저드의 기능이 있는 것” 과는 매우 다르다.
“8. 멀티 코어의 사용”은 내가 아직 대규모 프로젝트에 투입되지 않아봐서 그런걸까.. 하지만, 컴파일 시간이 그만큼 길다는 것은 그 프로젝트의 구성 자체가 문제일 가능성이 더 높다.
“9. MFC/ATL의 변화” 는 MFC의 클래스들을 MFC 이외에서 사용하고 싶은 욕심이 없어서일까..;;
써야 하는 이유의 대두분이 나한테는 아직 써야하는 이유로 다가오지 않으므로, 고로, 그래서, 나는 아직 VC++ 6를 쓸란다.
그리고, 또 다른 이유는 “내가 좀 많이 게으르다.” 라는 것이다. 흐흐….
..라고는 하지만 이렇게 결론내기 좀 부끄러워 몇마디 더 하자면, 툴은 익숙한 툴이 좋고, 상황에 맞는 툴을 골라서 사용할 줄 아는 것이 현명하다는 것이다. 그리고 현재 내 상황은 아직 VC++ 6이 가장 적합한 툴이다. 흐흐..