cdeclog

C++ 0x에 대한 리뷰 동영상인가 보다.

시간있을때 하나씩 정리를 해볼까 하는데.. 움..

2년전부터 항상 머리속에서 고민하고 있는 주제가 있다.
어떻게 하면 나의 머리속의 있는 내용을 문서로 정리할까 이다.

첨부터 오프라인 다이어리는 생각도 안했고 (요 부분은 내가 다이어리를 깔끔이 정리하는 능력이 없기때문에 ;;)
PDA나 핸드폰도 고민을 해보았으나 역시 입력장치의 불편함으로 인해 아니다 라는 결론에 도달했다.

물론 노트북도 대안이긴 하지만 회의시간에 항상 노트북을 들고 다니면서 타이핑을 하기에는 사람과의 커뮤니케이션이라는 부분에서 좀 아니다라는 생각이 들었다.

어찌 되었던 회의는 손으로 끄적거리면서 정리를 하고 그 내용을 파일로 정리를 하는것이 가장 낳겠다는 결론에 도달하고 그럼 어떤 어플리케이션으로 해야할지에 대해서 고민하기 시작하기 이른다.



1. 메일 클라이언트를 바꾸다 : 아웃룩 익스프레스-> 오피스 아웃룩
가볍다는 이유로, 오피스 제품을 따로 설치해야된다는 이유로(물론 회사에서는 라이센스가 있으므로 사용하면 된다.) 오피스 제품의 아웃룩을 배제 해왔다 .
또 메일 클라이언트로서의 기능이외에도 다른 기능들이 필요없었기 때문이기도 했다

허나 팀장의 직책을 맡은 이후로 메일량도 현저히 많아지고 내 작업 뿐만 아니라 다른 이슈사항까지 정리및 공유를 해야할 상황이 생겼다.
그리고 아웃룩 익스프레스의 한계(관리상의 한계도 포함)도 아웃룩으로 바꾸기에 충분한 이유를 제공해 주었다.

아웃룩으로 바꾼후 가장 좋은점중 하나는 메일마다 범주기능및 필터링 하기가 편해졌다는 점이다
메일에 대해서 경중을 나누기도 편하고 분류를 하기도 편해서 이런 부분에 대한 만족감은 기존에 사용하기전에 생각했던거 보다 좋았다.


2. 일정(약속, 회의)의 기록 -> 구글 캘린더
메일로 오는 일정을 일일이 범주나 구분으로 인해 기억하기는 그다지 효율적이라고 판단하니 않았고 때마침 구글에서 캘린더 서비스를 오픈했다.

웹으로 서비스를 하니 어느 컴퓨터에서도 접근및 수정이 가능했고 인터페이스도 나름 편했다
물론 초창기 버전은 개인적을 만족하지 못하는 부분이 있었지만 점점 낳아지고 있고 현재는 사용하기에 무리가 없을 정도로 발전을 한것같다 .


3. 생각의 정리 -> 스프링노트
현안을 정리하고 생각을 정리해야하는 툴이 필요했고 마침 스프링노트라는 서비스를 발견하고 사용하기 시작했다.
위키는 솔찍이 이지윅 에디터보다 불편한건 사실이고 접근성도 상대적으로 좋지 못했다 (적어도 나에게는...)

그래서 위키는 많은 노력(?)에도 불구하고 내 마음에서 사라져 갔고 화려한 UI보다는 글을 빨리 쓰고 정리할수 있는 웹툴이 필요했고 스프링노트가 나에 요구사항에 어느정도 부합했고 일정기간 사용을 했었다.

그러나 어느 이유에서 인가 슬슬 멀어져 가고...


4. 통합의 필요성 -> Outlook
아웃룩, 구글캘린더, 스프링노트.. 이렇게 3개의 툴을 사용하자니 점점 관리의 압박을 받기 시작했다
어떤 업무가 있다면 같은 내용을(물론 보는 관점에서는 틀리지만..) 3개의 툴을 띄어 작성을 하고 체크를 해야했다.

어느 순간 너무 비효율적이지 않는가 생각을 하고 통합에 대해서 생각을 하게되었다.
그리고 모든걸 담을수 있는놈은 역시 아웃룩이다 라고 생각을 하고 실행에 옮긴다.

구글캘린더의 내용은 다운받아서 아웃룩으로 옮기고 스프링노트의 내용도 아웃룩 일정의으로 옮겨서 사용하게 되었다.

인터넷으로 어디서든지 접근 가능성은..
어짜피 회사컴퓨터는 항상 켜있고 VPN으로 회사컴퓨터에 터미널로 접속을 하여 사용하는 되는것이다.


5. 분산저장관리및 동기화 -> Outlook - Google Calendar

유니코드 (네이버 백과사전)

유니코드는 전세계 문자코드를 정의하기 위해서 만든 놈이다

그럼 이전에는 어떻게 표현 했는가?

이전에는 알파벳틱한 애들은 1바이트에서 7비트 내로 표현하고(Ascii) 그외에 확장적인 문자가 코드 127 위로 표시되고, 한글과 같이 더 많은 바이트가 필요한 것들은 2바이트로 표현을 했다.

그래서 문제는 코드 127 위로 넘어가면 윈도우의 경우 각 나라의 OS별로 표현하는 방법이 틀렸다
(이전에 터보C 3.0 이전 IDE를 생각하면 될것이다. 콘솔화면으로 표현한 UI에서 옆에 테두리가 어떻게 나왔는지를...)

한글의 경우도 2바이트 문자로 표현을 하였고 이것을 MBCS(Multibyte Character Set) 이라고 한다.



UNICODE 

2바이트 문자를 표현하기 위해 만든 C++의 타입이 있었으니 그것이 바로 wchar_t 타입이다.
(그런데 wchar_t 의 경우 OS마다, 컴파일러마다 정의가 약간 틀린듯하다. -_-;; )

그럼 문자열을 어떻게 표현을 할까?
정수를 long 타입으로 표현할때 쓰는 뒤에 L를 붙이는것과 일맥상통 하게 앞에 L 을 붙여서 표현한다.



그리고 wchar_t 타입에 대응되는 표준 라이브러리들이 아래와 같은 놈들이다.

그리고 WinAPI 로는...

어라.. 근데 처음 보는 놈들일것이다.
MessageBox 는 알아도 MessageBoxW 는 무엇인가...
MSDN 를 뒤져도 찾기가 쉽지 않다.

WinAPI 에서는 문자열을 사용하는 API에 대해서 MBCS와 UNICODE에 대응되는 함수를 각각 가지고 있다.
그리고 거의 모든 API 에서 뒤에는 A(MBCS) 또는 W(UNICODE) 를 붙이는 것으로 표시를 하고 있는것이다.

그래서 MessageBox 라는 것은 함수 이름이 아니며 그것들을 스위칭 하는 매크로 이름이다.
실제 함수는 아래와 같이 MessageBoxA 혹은 MessageBoxW 로 매크로에 의해 치환되는것이다.

관련해서 타입들도 이런한 것들이 존재한다.

이 스위칭들은 UNICODE 와 _UNICODE 매크로 정의에 의해서 각각 해당 함수 혹은 타입으로 정의가 된다.
(UNICODE 와 _UNICODE 을 두개를 같이 정의 해야되는데 왜 2개를 만들었는지 모르겠다. 암튼..)

그리고 MSDN에서는 아래와 같이 함수인양 사기(?)를 치는것이다.

UTF-8, UTF-16 ??

위에서 얘기했듯이 일반적으로 유니코드는 2바이트 문자로 표현을 한다.
그러다 보니 한글 파일의 경우 MBCS나 UNICODE나 크기가 별반 차이가 없다.

그런데 영어권 애들의 파일을 보자..
게네들은 겉으로는 아무것도 낳아진것이 없는데 파일의 크기가 2배가 되어야 한다.
이런 어처구니 없는 경우가 있나..
(내가 생각해도 그렇다. 허나 뒤에가면 우리가 어처구니 없어진다. ㅎㅎ)

그래서 얘네들이 머리를 굴려서 유니코드를 표현하는 방식을 여려게 만들었다.
그것이 바로 UTF (Unicode Transformation Format) 이다.

그중에 일반적으로 유니코드라로 불리는 2바이트 체계 표현이 UTF-16 이고,
영어권은 1바이트 기타 언어는 4바이트까지 가변적으로 표현 가능한것이 UTF-8 이다.
(유니코드의 127 까지의 문자는 ASCII 문자코드와 동일하다. 그래서 영어권 1바이트가 ASCII와 호환이 되는것이다.)

http://ko.wikipedia.org/wiki/UTF-16
http://ko.wikipedia.org/wiki/UTF-8

이러다 보니 한글은 UTF-8 로 가면 4바이트로 표현이 되어 버린다. 


UTF-8 

그럼 UTF-8 은 어떤 타입을 써야 하는가? 
char [] 아니면 wchar_t [] ??

아직까지 표준으로 정해진것은 없는 것으로 안다.
차기 표준에서 이것에 대해서 논의가 되고 있으니 좋은 결과가 있을것으로...


Byte Order Mark

2바이트 혹은 그 이상의 바이트로 표현을 하다보니 정수표현과 같이 머신, 플랫폼 간의 바이트 오더링(little-endian, big-endian)의 문제가 있다.


유니코드 파일

윈도우 유니코드 파일의 경우 아래와 같은 문자를 파일 맨앞에 세팅함으로서 구분을 한다
(이게 표준인지 윈도우만 그런지는 잘 모르겠다...)

유니코드(UTF-16, little-endian) : 0xFF 0xFE
유니코드 big endian (UTF-16, big-endian) : 0xFE 0xFF
UTF-8 : 0xFE 0xFF

SQL Server 2005 버전 부터 기존 Native 확장프로시저의 개념으로 .net 환경의 CLR 코드의 통합을 제공한다

기본 네이티브 확장프로시저는의 문제점은 위험한 코드로 인해 SQL Server 자체의 보안이나 실행에 영향을 줄수 있다는것인데 2005 부터 지원되는 CLR의 경우 SQL Server와 실행의 완벽한 분리로 리스크를 최소한으로 줄였다고 한다.


이번에 SQL Server 암호화 모듈을 위해 Native 확장프로시저및 CLR 코드로 만들어 비교해 봤는데 CLR 의 압승이었다

Native의 경우 crypto++ 이라는 라이브러리로 래핑을 하였고 CLR의 경우 System.Security.Cryptography 의 라이브러리를 사용해서 만들었다.

대강의 느낌은 CLR 쪽이 3배 이상 빠른것으로 판단이되며 추측키로는 C++의 경우 확장프로시저 내의 객체 인스턴스 메모리의 할당하는 부분에서 승패를 가르지 않았는가 생각이 들지만 확인은 못해봤다.
아니면 알고리즘 구현 자체에 품질 문제 일수도 있을테고...

어찌 되었던 원래의 목적인 다중키 관리를 위해 키 저장소가 필요했고 키 저장소를 위해 xml 파일등 보다는 레지스트리에 저장을 하는것이 바이너리저장및 나름의 이점이 있지 않을까 생각이 들었고, 간단한 WinForm 을 제작하여 테스트를 해보았을때도 문제가 없었다.

그리고 CLR로 올리고 테스트 하는순간 레지스트리 접근을 못한다는것을 알았다

이유인 즉..
디폴트로 SQL Server CLR를 배포했을 경우 권한 수준이 "안전"(SAFE)수준으로 배포가 되어 SQL Server 이외의 리소스에 대해서 접근이 안됐다.

그래서 권한 수준을 "외부"나 "안전하지 않음"으로 배포를 해야 한는데 배포를 하면 다음과 같은 에러가 발생한다.


결론은 "권한이 있는 계정"으로 "TRUSTWORTHY 데이터 베이스 속성"이 되어있는 Database 에만 "외부"나 "안전하지 않음"의 권한 수준을 가지는 CLR를 배포할수 있다.

권한있는 계정은 sa나 그에 상응한는 계정으로 처리하면 되고 TRUSTWORTHY 데이터 베이스 속성은 아래와 같이 만들면 된다.

이번 CLR을 테스트 해보면서 거듭 느낀점은 .net 코드도 충분히 쓸만하게 성능이 나온다는것이다
경우에 따라서는 기존 native 보다 더 좋은 성능이 나오는것에 대해서 당황(?)을 하기도 하지만.. ^^


참고 :
http://technet.microsoft.com/ko-kr/library/ms345101.aspx
http://technet.microsoft.com/ko-kr/library/ms187861.aspx
http://msdn.microsoft.com/en-us/library/ms189524.aspx


ps.
위에 사항을 해결하기 위해 RegistryPermission 라는 클래스를 많이 찾아보았는다. (삽질..)
물론 직접적인 도움이 되지는 않았지만 먼가가 새로운 세계가 있는 갑다. 흐흐..

http://bobbyryu.blogspot.com/2008/09/blog-post.html

ex)
ADODB::_RecordsetPtr sp(GetDispatchPtr(var));

VB에서 Host 객체를 Early Binding 으로 호출 (컴포넌트를 참조한후 실행할 때..)
=> 3번만 호출

VB에서 Host 객체를 Late Binding 으로 호출 (CreateObejct 사용..)
=> 2번만 호출

VBScript 에서 Host 객체를 Late Binding 으로 호출 (VBScript 에서는 Late Binding만 지원)
=> 1번, 3번 호출

 

http://msdn.microsoft.com/en-us/library/bb978523.aspx
http://msdn.microsoft.com/en-us/library/bb735856.aspx


WCF의 COM+ 통합서비스

쉽게 얘기해서 COM+의 서비스를 종전의 DCOM이나 RDS처럼 WCF 여러 채널(바인딩)을 통해서 서비스 하는 방법이다

Binding	Interoperability	Transactions	Encoding
BasicHttpBinding	Basic Profile 1.1	(None)	Text, (MTOM)
WSHttpBinding	WS	(None), Yes	Text, (MTOM)
WSDualHttpBinding	WS	(None), Yes	Text, (MTOM)
WSFederationHttpBinding	WS-Federation	(None), Yes	Text, (MTOM)
NetTcpBinding	.NET	(None), Yes	Binary
NetNamedPipeBinding	.NET	(None), Yes	Binary
NetMsmqBinding	.NET	(None), Yes
NetPeerTcpBinding	Peer	(None)
MsmqIntegrationBinding	MSMQ	(None), Yes

여기서 WSHttpBinding과 BasicHttpBinding 과 같은 경우는 IIS를 통해서 지원을 하고,
NetTCPBinding 과 같은 경우는 COM+를 통해서 호스팅이 가능 하도록 설계되어 있다
물론 WAS(IIS 7.0)의 경우 모두 호스팅이 가능할 것으로..
(COM+ 통합의 경우 셀프 호스팅은 아직 안해봐서 모르겠다..)



WCF의 COM+ 통합서비스를 하려면 다음과 같은 도구가 필요하다

- .NET Framework 3.0 (or 3.5 ) (3.5를 설치하면 3.0, 2.0 등이 모두 설치된다.) - 3.5 권장..
- SvcConfigEditor.exe (Service Configuration Editor) 혹은 ComSvcConfig.exe

ComSvcConfig.exe는 .NET Framework 3.0와 함께 제공되며 커맨트 툴로 COM+의 WCF의 구성을 돕는다.
허나 .NET SDK로 제공되는  SvcConfigEditor.exe를 이용하면 Visual 한 환경으로 WCF 구성파일 편집, 생성및 COM+을 쉽게 구성할수 있다.

* ComSvcConfig.exe : http://msdn.microsoft.com/ko-kr/library/ms732009.aspx



구성 방법

1. 우선 만들어진 컴포넌트(VC++ ATL 간단하게 만들었다)를 COM+에 패키지를 생성하여 추가한다.

2. SvcConfigEditor.exe를 실행하여 "파일->통합->COM+응용프로그램" 메뉴를 선택
- COM+의 패키지의 컴포넌트 인터페이스를 선택
- 컴포넌트의 메서드 선택
- COM+ 호스팅 선택
- TCP를 선택
- 서비스 주소 세팅 (ex: net.tcp://localhost:9000/Simple)
- 완료

3. 2번과 같이 세팅이 완료된 경우 COM+의 해당 패키지의 등록정보-활성화 탭의 "응용 프로그램 루트 디렉토리"란에 WCF 설정파일이 생성된 디렉토리 경로가 세팅된다.
ex: C:\Program Files\ComPlus Applications\{593add39-f66f-442a-a901-01379dbac4eb}\

4. 그리고 netstat 로 확인을 해보면 hosting 이 되어 있는걸 확인할 수 있다.

위의 방법 이외에 웹호스팅으로도 선택하여 IIS를 통하여 서비스 하는것도 가능하며,
웹호스팅의 경우 웹사이트및 가상디렉토리를 선택하면 해당 디렉토리에 WCF구성파일을 생성해준다
(.svc 과 web.config)



테스트

위와같이 세팅이 되어 있다면 Visual Studio 2005 (Extensions for WPF and WCF 설치)나 Visual Studio 2008을 이용하여 테스트 가능하다

SvcUtil.exe 과 같은 툴로 스켈레톤 코드를 생성하여 포함시켜 사용해도 되고 VS 2008의 경우 서비스 참조를 하면 자동으로 생성을 해준다.

그리고 참조된 객체를 생성할때 생성자의 파라미터로 app.config에 설정되어 있는 endpoint 중에 하나를 선택하여 그 이름을 세팅하면 해당 endpoint를 이용하여 Communicaiton(통신)를 하게 된다.



그러나 처음 실행하면 다음과 같은 오류를 뱉어낸다.


이유는 COM+의 해당 패키지를 호스팅하는 프로세스가 객체를 자동 활성화 시키지 못해서 그런것 같다.
그러나 이미 활성화가 되어 있는 경우는 문제 없다.
어떻게 활성화를 자동으로 시킬지는 알아봐야 할듯...



위의 이유에서인지 MS에서는 WCF 서비스 형태로도 제공되는 COM+의 경우 해당 패키지를 서비스 형태로 실행하는 방법에 대해서 제시를 한다.

     서비스 COM+ 패키지 -> 등록정보 -> 활성화 탭 ->  "NT서비스로 응용프로그램 실행"

서비스 형태로 등록을 한 후 해당 패키지를 중지->시작 을 하면 서비스 형태로 실행이 되어 시스템 재시작 후에도 문제가 없다고 하는데...


기타

WCF의 COM+ 통합서비스를 하기 위해서는 XP및 Windows 2003 서버에 아래의 업데이트를 설치를 해줘야 한다.

Windows Communication Foundation용 업데이트(KB912817)

간략한 설명 :
MSDTC의 WS-AtomicTransaction 프로토콜에 대한 지원과 WCF(Windows Communication Foundation) COM+ 통합 기능에 대한 지원을 추가합니다.

http://sourceforge.net/projects/asio/

asio is a cross-platform C++ library for network and low-level I/O programming that provides developers with a consistent asynchronous model using a modern C++ approach.

asio 는 클로스 플랫폼은 지원하는 네트워크 라이브러리이다

ACE와는 비교도 안되게 가볍고 C++ 헤더로만 이루어져 있어 별도의 라이브러리 컴파일 과정이 필요없다.
그리고 각 플랫폼에 맞는 동기/비동기 모델을 하나의 인터페이스로 구현을 하여 유연성있는 네트워크 프로그램을 제공을 한다

boost 1.35부터 포함되어 있어 boost 라이브러리를 통해서 사용가능하고 직접 다운받아 stand alone 으로도  사용 가능하다


Download 쪽 항목을 보면 asio-tr2 라고 하는 패키지가 보이는데,
C++ tr2의 네트워크 라이브러리에 대한 제안서로 보인다.

개인적으로 tr2에 정의되어 있는 네트워크 라이브러리의 C++ 구현 인터페이스가 무지 궁금하지만,
asio 를 채택하는것도 그리 나쁜 선택은 아니라고 판단된다.


ps.
tr2의 내용중에 XML, HTML, Networking 같은 경우는 boost와 같이 C++ 계에서 주도적(?)으로
사용되는 것이 없어서 어떤 것들이 채택(혹은 구현)될지 궁금하다.

tr2의 주 내용

Unicode
XML and HTML
Networking
Usability for novices and occasional programmers

Herb Sutter 블로그의 C++ 0x 에 대한 리포트 링크 정리
http://herbsutter.wordpress.com/



http://herbsutter.wordpress.com/2007/05/10/trip-report-april-2007-iso-c-standards-meeting/

- 템플릿 별칭(aliase), 가변 템플릿 파라미터, using 용법 확장에 대한 내용들

http://herbsutter.wordpress.com/2007/09/10/trip-report-july-2007-iso-c-standards-meeting/

- 새로 추가되는 기능들에 대한 내용들
- constexpr, decltype  등...

http://herbsutter.wordpress.com/2007/11/01/trip-report-october-2007-iso-c-standards-meeting/

- C++ 0x 의 시기와 주요 컨셉에 관한 글
- nullptr 에 대한 소개
- threading, Concurrency, Atomic 에 관한 내용들

http://herbsutter.wordpress.com/2008/03/29/trip-report-februarymarch-2008-iso-c-standards-meeting/

- Lambda function and closure 에 관한 내용들

http://herbsutter.wordpress.com/2008/07/04/trip-report-june-2008-iso-c-standards-meeting/

- 초기화에 관한 내용들
- STL에서의 배열 초기화나 클래스 멤버의 초기화 문법에서의 초기화에 관한 이야기