C++Builder  |  Delphi  |  FireMonkey  |  C/C++  |  Free Pascal  |  Firebird
볼랜드포럼 BorlandForum
 경고! 게시물 작성자의 사전 허락없는 메일주소 추출행위 절대 금지
분야별 포럼
C++빌더
델파이
파이어몽키
C/C++
프리파스칼
파이어버드
볼랜드포럼 홈
헤드라인 뉴스
IT 뉴스
공지사항
자유게시판
해피 브레이크
공동 프로젝트
구인/구직
회원 장터
건의사항
운영진 게시판
회원 메뉴
북마크
볼랜드포럼 광고 모집

자유게시판
세상 살아가는 이야기들을 나누는 사랑방입니다.
[11681] Re:C++빌더를 고려하면? ^^
박지훈.임프 [cbuilder] 2886 읽음    2006-04-24 15:06
아래에 델파이의 장점을 위주로 글을 써봤으니 C++빌더를 위주로도 한번 써봐야겠다 싶네요. 사실 다들 아시다시피, 비주얼 C++에 대한 델파이의 장점은, 대부분이 C++빌더에도 해당합니다. 똑같은 VCL과, 똑같은 개발 방식을 이용하니까요.

한가지 빠진 것은 델파이에 비해 C++빌더의 컴파일 속도가 비교도 안되게 느리다는 건데... 이건 델파이와 C++빌더의 유일한 차이점이라고 할 수 있는 "언어"의 차이에서 오는 것이기 때문에 어차피 극복이 불가능한 거죠. 델파이 컴파일러의 환상적인 컴파일 속도는 제가 알기로는 컴파일되는 어떤 다른 언어와도 비교를 불허하는 지존(?)의 속도니까요. C++의 컴파일 속도가 느린 편이기도 하지만 그보다는 오브젝트 파스칼 언어의 컴파일 속도가 워낙에 탁월하다고 보는 것이 더 맞죠.

컴파일 속도 면에서는, 델파이가 아마도 영원히 최강 지존의 자리를 유지하겠지만, 그렇다고 해서 C++빌더가 델파이보다 못하다고 단정할 수는 없죠. C++ 언어를 선택함으로써 컴파일 속도를 희생한 대신, C++ 언어의 장점을 그대로 가져왔으니까요. 그럼 주정섭님의 말씀에도 불구하고 C++ 언어의 장점은 존재하는 걸까.. 그게 문제겠죠.

주정섭님도 인정하셨다시피, 템플릿 문법의 존재는 C++을 어떤 다른 언어와도 차별화되는 강력한 언어로 만들어줬죠. 아시다시피 템플릿이 존재함으로써 라이브러리를 극단적으로 범용으로 설계하는 것이 가능해졌습니다. 템플릿을 고려하여 만든 라이브러리와 그렇지 않은 라이브러리의 가용성을 생각하면 하늘과 땅 차이죠. (C#에서 템플릿을 도입할 거라고 하는 얘기를 들었는데, 좋은 기능을 다른 언어에서 따라가는 것은 당연하겠지만 성격과 목적이 다른 언어에서 C++에서처럼과 같은 그대로 가져갈 수는 없겠죠)

그러면, 템플릿 하나만 제외하면 C++의 장점은 전혀 없는 건가...라고 하면, 두가지가 아직 남았다고 생각합니다. 언어적인 면에서 살펴보면, 이건 정말 장점이자 단점인데, 개발자가 생각해낼 수 있고 필요로 할 수 있는 웬만한 문법은 다 추가되어 있다는 겁니다. C++은 언어적인 완성도나 습득하기 쉬운 정도(러닝 커브라고 하죠)를 고려하기보다는 개발자가 필요로 하는 스펙을 대체로 다 포용하는 쪽으로 발전되어 왔기 때문입니다.

하지만 주정섭님께서도 단호히(?) 무시하셨다시피, 이건 대부분의 개발자들에게는 장점보다는 단점이 되는 경우가 많습니다. 어떤 개발자도 그 많은 스펙들을 다 사용하지도 않고, 또 비교적 자주 언급되는 유명한 스펙들조차 과연 이게 꼭 필요한 것인가의 여부로 오랜 논란을 겪어왔으니까요. 더욱이 공부하는 초급자의 입장에서는, 언어의 스펙이 너무나 방대하고 난해하게 되는 결정적인 단점이 있습니다.

간단하게 말해서, 초보자의 입장에서 보면 이렇게 됩니다. C++과 오브젝트 파스칼이라는 두 언어에 대해 비슷한 수준의 문법서 혹은 입문서가 있다고 봤을 때, 당연히 C++쪽이 훨씬 두껍습니다. 만약 자주 사용되지 않는 문법까지 모두 포용한 문법 레퍼런스라면 그 차이가 몇배나 날 겁니다. 당연히 C++쪽이 공부하기가 훨씬 부담스럽습니다. 단지 부담의 차이면 다행이지만 C++ 문법서에 있는 모든 기능이 실무에서 반드시 필요한 것은 아니라는 것이 더 문제죠. 반대로 오브젝트 파스칼의 경우 거의 대부분이 실무에서 사용됩니다.

하지만 이런 방대한 C++ 문법에서, 개발자가 주관을 발휘해서 경우에 따라 어떤 문법 특징을 활용할 것인지에 대해 판단할 정도로 안목이 있다면 단점이 아니라 장점으로 작용하게 되죠. 그정도로 C++ 실력을 닦기가 쉽지 않다는 데 문제가 있습니다만. 실제로 중급 정도 레벨의 C++ 개발자가 상황에 맞지 않는 문법을 억지식으로 갖다붙여서 괜히 로직만 더 복잡하게 만든 경우도 종종 본 적이 있습니다.

아마도 많은 C++ 개발자들이 "C++ 온리!"를 외치는 배경에는, 다른 이유도 있겠지만 1이런 복잡한 언어 스펙의 특징 때문도 있다고 생각됩니다. 공부를 해도 해도 쉽게 끝나지 않는 C++의 특징을 절대적인 장점으로만 해석하는 편견 때문에요.

양날의 칼과 같은 이런 문법의 방대함을 제외하고, C++의 절대로 무시할 수 없는 최대의 장점은, 좀 우습지만 그 어떤 언어보다도 많이 사용된다는 것입니다. 지금은 자바의 점유율이 엄청나게 올라와서 C++을 위협할 정도가 되었지만, 아직도 C와 C++을 합하면 자바보다 점유율이 높다고 해외의 통계에서 말하더군요. 수십년동안 쌓인 C/C++의 레퍼런스를 고려하면 C/C++ 소스가 널린 정도는 아마 앞으로 십수년이 지나더라도 다른 언어에 밀리지 않을 겁니다.

이렇게 널린 소스가 많기 때문에 여러가지 부차적인 장점들이 생깁니다. 공개된 C/C++ 소스들을 그대로 가져다 쓸 수 있다는 것은 물론입니다. 또 대학 정규 과정에서 기본 C/C++ 문법을 배운 경우가 많으므로, 정규과정에는 대부분 없는 파스칼보다는 아무래도 접근하기가 편하죠. (물론 세부적으로 공부해나가면서 오히려 더 느려지는 단점을 논외로 하면 말입니다)

하지만 실무적으로 그보다 더 중요한 장점은, 수많은 서드파티 업체들에서 쏟아내는 그 많은 SDK들에서 나타납니다. 아시다시피 다이렉트X는 파스칼을 지원하지 않습니다. 3D 관련 툴들도 그렇습니다. 각종 하드웨어 업체들에서 내놓는 SDK들도 대부분 그렇습니다. 대부분 C/C++만을 지원하죠.

이런 SDK가 소규모일 때는 크게 문제가 안됩니다. 대부분의 소규모 SDK들은 dll과 C/C++ 헤더 파일 정도로 되어 있으니까, 양이 그렇게 많지 않다면 개발자가 직접 파스칼로 포팅해서 쓸 수 있으니까요. 하지만 SDK가 엄청나게 방대하다면? 이런 경우도 종종 있습니다.

얼마전에도 어느 지인이 델파이로 할 프로젝트에서 서드파티 SDK를 포팅하는 문제로 상담하러 찾아왔었는데, 그 어마어마한 규모를 보고 바로 델파이를 포기하라고 조언해주었습니다. 프로젝트 기간이 길어야 6~7개월인데, SDK 포팅만으로도 최소 4~5개월 이상 걸릴 것이 뻔해보였기 때문입니다. 더욱이 C++과 파스칼 사이에 문법 변환이 애매한 부분은, dll의 소스가 없는 대부분의 경우에는 변환을 시도해보고 제대로 전달되는지 오동작을 하지 않는지 여러 방법으로 테스트를 해볼 수밖에 없는데, 이런 종류의 테스트는 쉽게 안심하고 끝낼 수 있는 것도 아니까 더욱 그렇죠.

C++빌더를 사용하면 이런 종류의 문제들이 대부분 사라진다는 것이 중요합니다. C++빌더에서는 전통적인 C++ 언어식의 개발과 델파이의 VCL 방식을 다 선택할 수 있고, 한 프로젝트에서 섞어쓰는 것도 가능하죠. 개발자의 선택의 범위가 극도로 높아지는 겁니다.

간혹 제공되는 SDK가 비주얼 C++용으로만 제공되어서 문제가 되는 경우도 있는데, 물론 이런 SDK는 C/C++을 지원하는 것이 아니라 비주얼 C++을 지원하는 거죠. 특히 dll에서 변수의 전달에 MFC를 사용하면 비주얼 C++외에는 사용하지 말라고 하는 셈입니다. 이런 경우가 아주 드물지는 않지만, 대부분의 C/C++용 SDK는 그렇게 하지 않죠.

lib 파일이 비주얼 C++ 형식으로 되어 있어서 문제가 된다고 하는 분도 있지만, dll에 종속된 lib 파일은 어차피 dll의 임포트 라이브러리일 뿐이므로 implib 유틸리티에서 dll에서 새로 생성해낼 수 있습니다. 결과적으로 SDK에서 lib 파일은 별로 필요가 없고, 중요한 것은 dll과 헤더 파일 뿐이죠. (사실 델파이에서는 dll을 링크할 때 임포트 라이브러리 파일 자체가 아예 필요없죠. 임포트 lib 파일은 스텁일 뿐이니까요.)

그러면, 이렇게 C++빌더가 뛰어난데, 거꾸로 생각할 여지는 없을까... 델파이가 필요가 없는 거 아닌가 하는 거 말입니다. 그렇지도 않습니다. 주정섭님께서 말씀하시는, 델파이의 엄청나게 빠른 컴파일 속도도 분명히 개발에 있어 중요한 요소입니다. 또 컴파일 속도 외에도, 델파이의 오브젝트 파스칼 언어는 C++보다 훨씬 배우기가 쉽고 간략하다는 장점이 있습니다.

또 어떤 관점에서 보면, 템플릿 정도를 제외하면 오브젝트 파스칼에 채용된 문법 외에 C++이 추가로 가지는 많은 문법들이 실제로는 그다지 많이 사용되지 않기 때문에 공부하는 입장에서는 C++의 방대한 문법 스펙들이 부담밖에 안될 수도 있습니다.

이런 이유로 저는 개발툴들 중에 비슷하다고 간주되는 C++빌더와 델파이 사이에서도 차별성이 있고, 선택을 위해 시간을 들여 고민할 가치가 있다고 생각합니다.

예를 들어 당면 프로젝트의 요인들 때문에 언어 자체가 정말로 중요할 경우. 많은 경우에 C++이 필요하기도 하고, 좀 소수이기는 하지만 델파이를 요구받기도 합니다. 이런 경우에는 가장 우선적으로 그런 언어적인 요소를 따라갈 수밖에 없죠.

또 공부하는 개발자의 입장에서 생각해보면, 어떤 식으로든 C/C++ 언어에 상당히 익숙한 경우라면 당연히 C++빌더를 선택하라고 권하고 싶습니다. (물론 학교에서 C++을 배우기는 했는데 몇년이 지나 싹 까먹었다면 고려 사항이 아니겠죠.) 언어가 C++이라는 장점은 현재의 SW 업계 판도와 인식을 감안하면 절대로 무시할 수 없는 장점입니다.

하지만 C++에 상당히 익숙한 경우가 아니고, 또 상황상 C++이 강력하게 요구되는 경우가 아니라면 델파이가 낫습니다. 문법적으로도 간략해서 익히기가 비교적 쉬우면서도 구현을 위해 필요한 모든 기능은 다 있습니다. 또 공부한 델파이 문법은 반드시 쓰입니다. 공부하는 입장에서 이보다 좋을 수가 없죠.

하지만... 원래의 논점으로 돌아가서, 비주얼 C++이라면 그다지 논할 가치를 못느끼겠습니다. 개발툴 자체가 많이 쓰인다는 단 한가지의 장점 외에는(물론 이것이 현실에서 많은 경우 무시할 수 없는 것이지만), C++빌더와 델파이에 비해 개발툴이나 언어적인 면 등등 모든 면에서 어떤 장점도 없다고 할 수 있지요.
해롱해롱 [seaeast2]   2006-04-24 15:21 X
그런데 궁금한게.. 도대체 C++의 어떤 문법이 그렇게 난해하고 복잡하다고 하는것 인지요? 물론 함수포인터와 배열로 꼬아 만든 포인터 연산은 좀 그렇습니다. 그리고 다중 상속쪽에도 약간 문제들이 있긴 하지만, 그다지 어려운 내용은 아니라고 봅니다. 몇번 써보면 금방 익숙해 지는 내용들 이니까요..
BloodWolf [cyberpd]   2006-04-24 15:53 X
template으로 넘어가면 그 난해함에 악마적 음모를 느낌니다. :-)
해롱해롱 [seaeast2]   2006-04-24 17:32 X
템플릿 한번 잘 공부해 놓으면 그다지 어려울것 없습니다. 단지 눈에 <> 의 사용으로 인해 불편해 보일뿐...
nicekr.황경록 [mpbox]   2006-04-25 13:12 X
^-^오랜만에 들어왔더니 잼난 글들이 많군요 ^^~ 우리 모두 해탈의 경지로~-.-;;;; 모든 Object는 그 나름대로의 쓰임이 있고 그 Object를 어떻게 어느부분에 사용하는가는 전적으로 그 Object를 가져다 쓰는 사람의 책임이다라고 말하고 싶네요 ^^.. Objective 를 명확히 해서 필요한 Method 를 구현가능하다면? 그렇게 해야겠죠? 헤헷;;; 이게 도통 무슨소린지 ^^''''

+ -

관련 글 리스트
11676 델마당 자게의 "델파이의 한계를 극복하는 길은 C++ 인가"에 글에 대한 유감 주정섭 3860 2006/04/24
11681     Re:C++빌더를 고려하면? ^^ 박지훈.임프 2886 2006/04/24
11678     Re:그에 대해 델마당에 썼던 글... 박지훈.임프 2305 2006/04/24
Google
Copyright © 1999-2015, borlandforum.com. All right reserved.