3월 18일~19일 대전과 서울에서 "C++Builder XE5 따라잡기 LIVE!" 주제로 C++빌더 세미나가 있었습니다.
그 내용을 간단하게 리뷰합니다.
우선 대전과 서울의 분위기를 살짝 알려드리자면, 대전은 저희가 예상했던 참석율을 훨씬 웃돌았습니다. 신청하신 대부분의 분들이 참석해주셨고, 신청하시지 않고 오신 분들도 몇분 계셨습니다. 지방에서도 더 많은 세미나등 이벤트를 만들어야 겠다는 생각을 했습니다. 서울도 마찬가지로 신청하신 분들이 대부분 참석하셔서 데브기어 세미나장이 꽉찬 상태에서 아주 성황리에 진행 되었습니다.
Gordon Li
볼랜드부터 DevCo, CodeGear에 이어 현재 Embarcadero(엠바카데로)의 중국, 대만, 아세안 지역의 수석
에반젤리스트로 활동중입니다. Delphi와 C++Builder에 대한 기술 경력이 깊고 풍부하며, 20여권의 도서를
집필하였습니다. Run! IT, CSDN 등에 100여 개의 아티클을 기고하는 등 저명한 필자로도 왕성하게 활동하고
있습니다.
발표 주제는 C/C++ 데스크탑과 모바일 개발의 제왕이라는 주제로 진행되었습니다.
The Big Picture
초반 개발트랜드를 소개하는 시간을 갖었습니다.
최근 한 연구기관을 통해 윈도우와 모바일 개발자 천여명에게 윈도우에 머무를 것인지, 모바일로 갈것인지에 대해 설문한 내용을 소개했습니다.
우선 95%의 개발자들은 윈도우 개발을 지속적으로 진행할 것이라 답했고, 동시에 83%는 안드로이드에 67%는 iOS가 가장 중요하다고 답을 했습니다. 결과적으로 윈도우와 모바일 모두 중요하다는 결과를 확인했습니다.
그리고, 85%의 응답자들은 UX와 성능을 위해 Scripted/interpreted 기반 솔루션보다 네이티브 앱을 원한다는 결과를 확인했습니다.(만약, 웨어러블 디바이스 용 앱을 만든다고 생각하면 결과에 대한 이해가 더 확실할 것입니다.)
마지막으로, 95%의 응답자들이 기존의 소스코드를 모바일에서도 사용하기를 원했습니다.
위의 설문조사를 통해 대부분의 개발자들은 각각의 플랫폼별로 따로 개발하는 것보다 하나의 소스코드를 통해 다양한 모바일 플랫폼과 데스크탑을 함께 개발하고 싶어하고, 성능이나 UX를 위해 네이티브 앱을 개발하고 싶다는 결과를 확인했습니다.
그리고, 그 대부분을 이미 C++빌더가 지향한다는 설명을 들었습니다.
C/C++: King Of Cross-Platform Development
다들 아시다시피 전통적으로 C와 C++ 소스코드는 다양한 장비에 들어갔었고, 윈도우, 유닉스, HP, 메인플랫폼 등 다양한 플랫폼과 장비에 올라가는 컴파일러 입니다. 예전에는 대부분의 장비가 C/C++로 되어 있었지만, 모바일에서는 왜 C/C++로 개발할 수 없는지 고든은 의아해 했다고 합니다.
그리고, 몇주전 발표된 CarPlay와 그 뒤를 따른 구글의 차량용 기술이 발표되었고, 기존에는 스마트폰이나 웨어러블 디바이스 개발만 가능한 줄 알았지만, 이제는 차량용 앱도 만들 수 있겠다고 생각했다 합니다.
C/C++은 Ansi C 위원의 주도하에 구준하게 기능이 추가되고 있습니다.
80년대에는 다양한 컴파일러간의 성능 및 최적화로 경쟁하는 시기였다.
90년대에는 다양한 컴파일러가 사장되고 3개의 메이저 컴파일러가 최적화 이후 데스크탑 및 C/S환경을 어떻게 개발할 것인가에 대한 경재하는 시기였습니다.
2000년대는 유니코드와 64bit등으로 경쟁하였으며, 볼랜드C는 컴파일러 등에 투자가 적어 사양되고, C++빌더가 생성성을 앞세워 출시되었습니다.(이시기에 C++빌더는 최적화등에 뒤쳐져 컴파일 속도가 경쟁 컴파일러에 뒤쳐지게됨)
2010년대는 크로스 컴파일 및 다양한 장비가 등장해 이에 대응하는 시기가 될것이다.
사실 C++빌더의 컴파일러 속도가 느리다는 걱정은 안해도된다. 왜냐하면, 64bit llvm의 clang 컴파일러를 사용해 가장 빠른 컴파일러로 탈바꿈되었다. 그리고 C++로 구글글래스 개발에 대해 검색하면 마음에 드는 방법이 나오지 않을 것이다. gcc가 가능하지만 구글글래스를 컨트롤하기에 아주 많은 시간이 걸릴것이다. 헬로우 월드를 만드는 것도 3~4개월의 시간이 걸리지 않을까 싶다. 하지만 C++빌더를 사용한다면 하루에 가능하다.
C++ 컴파일러간 속도를 분석한 글을 소개했는데요. 이 글에서는 다양한 C++컴파일러간의 속도를 측정하고 성능을 기록했습니다. 결과는 너무 멋지게도 llvm이 적용된 C++빌더가 가장 뛰어난 성능을 냈다는 글입니다. 직접 확인해 보시면 아주 좋습니다.
http://slashdot.org/topic/cloud/speed-test-2-comparing-c-compilers-on-windows/
어도비에서 제공되는 소스코드를 통해 C++ 속도를 측정할 수 있습니다.(다음의 데모는 이 소스코드로 진행되었습니다.)
http://stlab.adobe.com/performance/
실제 데모를 통해 llvm의 성능을 확인하는 데모가 진행 되었습니다.
2배~5배이상의 개선된 속도를 확인할 수 있었습니다.(bcc 32bit vs llvm 64bit)
llvm은 개발자가 작성한 코드를 최고의 성능을 내도로 최적화 하는 작업을 진행합니다. 그래서 같은 코드라도 llvm 컴파일러는 더 좋은 성능을 낼 수 있습니다.
(예를 들면 반복문(loop)에서 상수등과 같이 변하지 않는 코드는 최적화 과정에서 루프 밖으로 빠지고, 한번만 수행되도록 최적화 됩니다.)
Introducing FIREDAC
FireDAC은 BDE, dbExpress, ODBC등의 전통적인 데이터 엑세스에서 모바일에서 다양한 엑세스를 지원하기 위한 새로운 데이터 엑세스 컴포넌트이다.
FireDAC의 경우 별도의 데이터 엑세스 클라이언트를 설치하지 않고 Native Driver를 통해 각 DBMD에 직접(Direct) 접속이 가능하다.
BDE와 매우 비슷하지만 성능 및 사용성이 매우 좋다. 그리고 일관성 있는 Interface로 여러가지 DB플랫폼에 접속이 가능하다.
실제 데모를 통해 dbExpress보다 개선된 속도와 DML을 이용할경우 10배이상 개선된 속도를 확인할 수 있었다.
(2000건의 데이터 Insert 기준)
One Codebase, One Team, One Schedule
제일 중요한 가치인 하나의 코드와 하나의 팀, 하나의 스케쥴 그리고 예산에 대해 설명을 했습니다.
하나의 제품을 플랫폼 별로 다르게 개발하면 여러개의 팀과 그 팀간의 스케쥴이 복잡해 지고 결과적으로 너무나 많은 예산이 들지만, 하나의 코드로 하나의 팀을 운영한다면, 하나의 스케쥴로 진행이 되어 예산도 상당히 아낄수 있습니다.
당연히 기업의 입장에서는 가야할 길인 것 같습니다.
대만에 있는 DataSnap 서버와 연동하여 PC와 모바일용 앱을 시연했습니다. 스케쥴을 다운로드하고, 현재의 위치를 체크인하고, 지정된 스케쥴에 노트를하고 상태를 바꾸는 앱을 아주 쉽게 만들 수 있을것 같습니다.
새로운 REST Client를 소개하고 대만의 시에서 제공하는 자전거 점포 정보를 Rest API를 기반으로 아주 쉽게 모바일 서비스를 만드는 방법을 설명과 데모로 진행 되었습니다.
여러분들의 데이터는 DataSnap 또는 BAAS(Backend As A Service)를 통해 PC와 모바일로 아주 쉽고 편리하게 데이터를 연동할 수 있습니다.
세미나의 내용을 글로 표현한다는것이 참 어렵습니다. 그 당시의 분위기와 열기를 빼니 글이 건조해지는 느낌이네요^^
세미나에 참석하지 못하신 분들을 위해 간단하게나마 글로 대신했지만, 다음 기회에는 꼭 세미나에 참석하셔서 현장의 분위기를 느껴보시길 부탁드립니다.
감사합니다.
