질문 및 요청 좀 드립니다.
2013.05.13 14:09
안녕하십니까?
RAD Studio XE 버전들에 관심이 많은 사람입니다. XE4 평가판을 써봤습니다..
몇가지 질문 및 요청사항이 있어서 적습니다.
1. 동영상 자료들을 좀 더 원활히 보고 계속 반복해서 보고 싶어서 다운로드를
하고 싶어서 엠바까데로 사이트에 가입까지 했으나 자막을 얻을 수 없어서
좀 그렇습니다. 자막 파일만 좀 따로 올려주실수는 없는 것인지요? 꼭 인터넷
되는 환경에서 봐야만 하는 것인지요.. 따로, 자막을 좀 올려주시면 편의성을
훨씬 고려해주시는 처사일 것으로 생각됩니다만..
2. 다들 느끼는 것이겠지만 이번의 XE4 는 델파이 사용자의 전유물이 되었습니다.
알다시피 델파이 사용자들 만큼이나 이 혁신적인 C/C++ 빌더 XE 버전에 기존 VC++
사용자들도 관심이 많습니다. 그런데, 이번 버전은 반쪽짜리 혁신이 아닌가 생각이
됩니다. 그게 아니라면 설명이(리소스) 매우 부족한 상황인 것 같습니다.
왜 그렇게 생각하냐면 델파이에만 모바일 개발메뉴가 들어가있기 때문이지요.
그래서 델파이로만 iOS 네이티브 컴포넌트가 지원되고 있다는 점으로 인하여
C/C++ 개발자들은 소외된 느낌을 받습니다. 이게 기술적으로 지원이 안되는
것인지 차후에 지원이 될 것인지 혹은 앞으로도 지원할 생가기 없는 것인지에
대해서 밝혀주셔야 할 것 같다는 생각이 듭니다. 어딜 보더라도 다 멀티디바이스를
말하고 있고 C/C++ 빌더까지 넣어놓았음에도 불구하고 델파이에서만 네이티브
컴포넌트를 지원하고 있다는 것은 석연찮은 구석이 있습니다. 거짓말을 하는 것처럼
보인다는 것이지요.. 왜냐면, 개인적으로는 C/C++ 빌더에서 조차도 iOS 네이티브
컴포넌트까지 사용하는 UI 개발환경까지 지원한다면 거의 혁신이라고 생각했거든요..
그런데, 역시나 아니더군요.. 파이어몽키 프레임워크가 기존에 게임엔진들 렙핑해놓은
것 정도로 생각하고 있었기 때문에 델파이는 몰라도 C/C++ 언어로는 네이티브는
사실 기대도 안했었는데 이번에 광고를 보고 놀랬었습니다. 그런데, 역시 아니더군요..
뭔가 잘못된 정보를 뿌리고 있다고 생각안드십니까? 좀 확실히 밝혀 주시는게 유저들이
사기당했다는 생각이 안들게 해줄거 같습니다. C/C++ 빌더는 iOS 네이티브 UI 컴포넌트
지원이 안된다 파이어몽키로 가짜 UI 를 사용해야한다라고 명시해주시라는 것이지요..
괜히 다들 농락당했다고 생각하지 않게 말입니다.. 아니면, 차후 지원방향이라도 알려
주시던가요.. 여튼.. C/C++ 유저로써 솔직히 기대를 했었는데 실망이 적잖이 있습니다..
3. XE3 로 간단한 개발을 해보았었는데 굉장히 불편한 점을 겪게 되었습니다. 어떤 점이냐면
기존에 소스들이 호환이 거의 안되는겁니다. 그 이유인즉 거의 반 강제로 유니코드 지원이
되고 있었기 때문입니다.. 잘 아실지는 모르겠으나 대부분의 C/C++ 사용자들은 ANSI 기반의
코드로 작업을 합니다. 왜냐면 C/C++ 프로그래머들은 스트링을 다루는 것 만큼이나 데이타를
많이 다루는데 기본적으로 이 데이타를 스트링처럼 1 바이트 단위로 많이 다룹니다. 즉,
char * 나 unsigned char * 의 비중이 무지막지하게 크게 차지하고 있는 분야가 C/C++ 분야라는
것이지요. 그런데, 현재 XE 버전은 유니코드를 거의 반강제로 지원하고 있는 관계로 본인이
C/C++ 코드를 짜는 것이지 외계인 코드를 짜는 것인지 분간하기 힘들정도로 유니코드형식에
맞춰주느라 코딩을 불편하게 만들더군요.. 아예 유니코드 지원용 프로그램이라면 차라리 따로
짜는게 더 편리할 정도라고 느껴질 정도라고나 할까요.. 대부분의 프로그래머들은 여태까지
유니코드가 필요한 부분은 직접 해당 부분만 변환하면서 해왔는데 이번에는 거의 반강제로
적용되어 있어서 상대적으로 데이타를 다뤄야 하는 중요한 부분에서 변환을 거치는 선후가
바뀌었다는 것이죠.. 예를하나 들어보면 네트워크에서 데이타를 받았는데 아스키(8비트:1바이트)
데이타입니다. 그런데, 이 데이타를 컴포넌트들을 통해서 받으면 2바이트 문자열 UnicodeString
으로 처리해야하는 상황이 된다는 겁니다. C 사용자는 a 로 받으면 a[0] == 'A' && a[1] == 'B' 뭐
이런식으로 처리를 하려는 경우가 다반인데 이런 처리를 할려면 AnsiString 변수를 만들어서
다시 1바이트 처리로 바꿔서 해야하는 경우가 생기더군요.. 그래서 기본모드 자체를 유니코드
wchar_t 로 처리되지 못하고 무조건 1바이트로 인식되게 하는 옵션이 있는가 찾아봤습니다.
map 어쩌구하는 옵션이 있어서 그걸 char 모드로 바꾸고 해봤는데 역시나 2바이트 문제를 피해
가질 못하더라구요.. 심각하다는 생각이 들었습니다. 기본적으로 C/C++ 프로그래머들은 여전히
유니코드 기반의 프로그램보다는 ANSI 기반의 프로그램을 더 많이 더 자주 만들고 있는데 말이에요..
개인적으로 엠바까데로에서 좀 잘못만든게 아닌가 하는 생각마져 듭니다.. 유니코드는 기존처럼
선택적으로 지원하고 기본은 무조건 ANSI 기반으로 해줘야 기존의 코드들과도 호환이 잘되고
심지어 C/C++ 프로그래머들이 제일 많이 하는 소스 copy & paste 시에도 호환성이 높아질텐데
이점 때문에 그런걸 다 막고 있다는 느낌이 듭니다. 소스를 하나 복사해서 사용할려고 해도 죄다
유니코드화로 강제로 변환시켜주려니 여간 짜증나는게 아니더군요.. 기존에는 그냥 win32 api 로
짜여진 코드도 복사해서 사용해도 큰 탈이 없었다면 이번에는 너무 많은 수정을 해줘야 한다는
것이지요.. 게다가 중간에 a[0] == 'A' 뭐 이런식의 바이트 체킹 부분 코드라도 있다면 완전 심각해
질 수도 있구요.. 손이 많이 간다는 것임.. 그래서 이런 부분에 대해서 어떻게 생각하시는가와..
엠바까데로사에 어필하실 의향이 있으신지와 또 해결방법(옵션이 있나요?)은 있는지 듣고싶습니다.
다 좋아졌지만 C/C++ 프로그래머 입장에서는 거의 베려를 안해주는 것을 보아 델파이 전유물이
되가는 것 같다는 생각이 듭니다.. 제가 괜히 기대를 하는 건지요.. 그냥 노가다의 신인 VC++ 에 뼈를
묻어야 하는 건지요..
여튼.. 긴글이지만 문의드려봤습니다..
