오랜만에 C++ 코드를 작성하고 있습니다. C#으로 WPF/Silverlight 만 다루다가 오랜만에 C++로 ATL/COM을 만지려고 하니 사소한 것에서 난관이 많네요. 툴도 바뀌기도 했고 말이죠. 오랜만에 C++을 쓰다보니 새로 알게 되는 지식도 생기는군요.

Visual C++ 2010 에서는 STL 컨테이너에 대해서 for each, in 구문을 사용할 수 있다는 걸 알게되었습니다. (MSDN 문서 항목을 보면 2005 버전부터 존재하긴 합니다.)

도입된 목적은 역시 C++/CLI 에서 IEnumerable 등의 형식을 순차적으로 처리할 때 C#의 foreach, in 구문과 동일하게 쓰기 위한 것으로 보입니다. 하지만 C++/CLI가 아닌 win32 프로그래밍에서 STL 컨테이너에 대해서도 사용할 수 있는 것이지요.

Visual C++ 2010 에서는 c++0x 표준안의 일부가 이미 포함되어 있기에 아래와 같이 별로 C++ 스럽지 않은 코드가 나오게 됩니다. (c++0x는 이제 ISO C++ 표준으로 승인이 되어 C++11 이라고 부르는 것이 정식입니다.)

	
        std::<CString, CString> _uriMap;
        std::list<CString>&& candidates = GetUriMappingCandidates(uri); // r-value reference
	CString foundKey;
	CString foundValue;
	for each (auto c in candidates)
	{
		auto it = _uriMap.find(c);
		if (it != _uriMap.end()) 
		{
			foundKey = it->first;
			foundValue = it->second;
			break;
		}
	}

C++11의 auto 키워드와, 비록 비표준 키워드이긴 하지만 for each 를 써주니까 STL 컨테이너를 두 가지나 사용하고 있는데도 예전처럼 콜론과 부등호가 난무하지 않고 코드가 깔끔해보여서 좋네요.

며칠 전에 Visual Studio 2010에서 확장 기능 갤러리 구경하다가 인기 항목에 있길래 깔아봤는데 썩 괜찮습니다.

C# 작성할 때에는 깔끔하게 정리하려고 region 이라는 Preprocessor 블락을 많이 쓰는데요, 남이 만든 코드이거나 코드가 길어지면 어떤 영역들이 만들어져있는지 잘 찾기 힘들어서 정리하는 의미가 줄어들곤 했습니다.

그런 가려운 부분을 잘 긁어주는 확장 기능입니다. 코드 레이아웃을 잘 보여줘서 region의 활용도를 더 높여주고요, 추가로 메소드 바로가기 같은 걸 상단에 등록해서 코드 분석할 때에도 유용합니다.

MVVM 패턴을 사용할 때 초기화하는 패턴만 대략 10가지 정도의 패턴이 있습니다. 그중에 Expression Blend와 VisualStudio의 디자인 타임에 잘 보이게 하려면 리소스에 ViewModel Locator를 넣는게 가장 좋습니다.

당연히 중복을 피하고 싶고 컨트롤마다 로케이터가 생성될 필요는 없으니 Window나 UserControl 모두에 Locator 리소스를 넣기보다는 App의 리소스(글로벌 리소스)에 넣는 방법이 먼저 시도되는 것이 바람직합니다.

그런데 여기서 디자인타임 지원에 문제가 생깁니다. Blend에서 윈도우나 사용자컨트롤에 포함되어 있는 사용자컨트롤을 생성할 때, 글로벌 리소스에는 접근할 수가 없는거죠. 검색을 좀 해보면 이것을 Blend의 버그로 보는 경향이 많습니다. 몇가지 해결책도 제시하고 있는데 완벽하지는 않습니다.

결국 컨트롤마다 XAML의 리소스 사전에 로케이터를 정의하는 방식으로 선회할 수 밖에 없었습니다. 이때 우리를 구해준 것이 IoC 컨테이너였습니다. MVVM Light를 사용하는 프로젝트라서 사실은 이미 SimpleIoc라는 내장 IoC 컨테이너가 사용되고 있는 상황이었지요.

IoC 컨테이너 자체가 이미 싱글턴이고, 이 싱글턴 인스턴스가 하는 일은 사용자가 등록해둔 타입별 인스턴스를 관리하는 일입니다. 즉 프로그램의 어느 부분에서나 쓰고 싶은 타입만 지정하면 그 타입의 동일한 인스턴스를 얻을 수 있다는 거죠.

그래서 ViewModel Locator를 모든 컨트롤에서 매번 생성하는게 아무 문제 없는 거였습니다.

MVVM 패턴을 쓸 때 걱정했던 부분이 패턴 자체의 학습 곡선이었습니다. 그리고 부가적으로 따라올 것처럼 보이는 다른 패턴들에 대한 학습이었습니다. 확실히 학습에 시간을 좀 더 쓰게 되는 것 같기는 합니다. 하지만 다행히 MVVM Light 프레임워크가 적절한 수준에서 문제 범위가 너무 커지는 걸 막아주었다는 생각이 듭니다.

iPhone 에서 작성된 글입니다.

"윈도우 8, PC와 태블릿 SW 호환안돼"라는 블로터닷넷 기사를 보고 관심이 생겨 살짝 구글링 하다가 Win 8에 추가되는 Windows Runtime(WinRT) 라는 녀석에 대해 기술적으로 설명한 글이 있어서 공유합니다.

원문 : Microsoft's high-risk Windows 8 .NET switch - Revenge of COM, or something like it

원문을 쓴 사람은 MS가 태블릿 환경에서 아이패드를 따라잡는 것을 가장 중요한 목표로 잡고 있다고 보고 있네요. 그래서 모든 에너지를 WinRT 기반의 메트로 앱과 클라우드 환경에 쏟고 있다고 보고 있습니다. (닷넷과 실버라이트는 뒷전이라는 얘기죠.)

아래 내용은 제가 요약한 버전입니다.

WinRT : COM으로의 회귀(혹은 아주 비스무레한 새로운 녀석)

MS는 터치 인터페이스에 잘 어울리는 기반이 필요했다. 윈폰7에서 닷넷 기반 XNA나 실버라이트를 시험해 봤지만, 결국 새 API 모델을 만든 셈이다.

WinRT는 닷넷에 의존하지 않는다. 닷넷이 등장하기 이전에 윈도우를 구성하던 COM 스타일의 런타임이다. 거기에 닷넷에서 가져온 메타데이터 시스템을 채용하여, .winmd 라는 파일에 메타데이터를 저장한다. 그 덕분에 닷넷, C++, IE 엔진에서 모두 호출할 수 있는 런타임이 되었다. UI는 WPF/Silverlight에서 사용하던 XAML 을 채용했지만, 닷넷 기반이 아니라 Native 로 재작성한 것이다.

메트로 스타일 앱 환경 자체는 실버라이트와 비슷한 보안 모델을 사용하고 있어서 굉장히 제한적이다. 네이티브 DLL을 만들 수 있지만, 역시나 허용한 기능만 사용할 수 있다. 다른 앱과 공유된 익스텐션을 만들 수 없게 되어 있다.  파일 I/O 도 앱 전용 Isolated Storage에 대해서만 허용된다. (거의 애플 iOS 의 어플리케이션 모델과 비슷하게 보이네요.)

메트로 스타일 앱을 위한 UI 시스템은 프로그래머들이 사용하기 쉬우면서도 높은 성능을 제공한다. 모든 화면은 DirectX로 렌더링된다. 또한 비동기 프로그래밍 기능이 아주 쉬워졌다. await 라는 새로운 키워드가 제공되어, 프로그래머는 동기적인 것처럼 간단히 프로그래밍하면 내부적으로는 콜백을 써서 비동기적으로 동작한다.

추가로 InfoQ의 WinRT: An Object Orientated Replacement for Win32 라는 포스트도 참고할 만 합니다.

제가 겪은 상황은 빌드해서 실행하면 ZKFileArchive 내부에서, [NSCFString zk_precomposedUTF8Length] unrecognized selector sent ... 라는 에러가 나는 상황이었습니다.

이 상황은 ZipKit 의 이슈트래커에도 올라와 있더군요. ( #22 zk_precomposedUTF8Length unrecognized selector sent to instance )

해결책은 해당하는 타겟의 빌드 설정에서 Other Linker Flags 에 -Objc 와 -all_load 플래그를 추가해주는 것이었습니다.

Objective-C로 iOS 개발을 할 때 retain count 를 잘못 관리하여 EXC_BAD_ACCESS 에러가 발생하면서 프로그램이 종료되는 문제를 디버깅할 때 사용할 수 있는 팁에 대한 글입니다.

EXC_BAD_ACCESS 메모리 문제 디버깅하기

SHFB(Sandcastle Help File Builder)를 이용하여 .NET 프로젝트 문서화를 할 때(코드주석 문서화하자 참조) namespace에 해당하는 페이지에서는 항상 문서화 주석이 없다는 붉은 오류 메시지가 포함되어 상당히 보기 안좋았는데, 오늘 잠깐 검색을 해서 방법을 찾았습니다. 이것은 SHFB에 포함된 도움말의 색인에서 NamespaceDoc class 항목을 찾아보면 볼 수 있는 내용입니다.

해당 네임스페이스에 NamespaceDoc 이라는 클래스를 만들고 그 클래스에 문서화 주석을 달면 SHFB가 빌드할 때 네임스페이스 도움말로 바꿔줍니다. 아래와 같은 코드를 만드는거죠.

namespace TheNamespace
{
    /// <summary>
    /// 이 네임스페이스로 말할 것 같으면, 아무튼 멋지구리하다는 것!
    /// </summary>
    [System.Runtime.CompilerServices.CompilerGenerated]
    class NamespaceDoc
    {
    }
}

이렇게 써주면 TheNamespace 에 해당하는 도움말 페이지에는 NamespaceDoc 클래스의 문서화 주석 내용이 표시되는 겁니다. 이제 더이상 별로 보기 안 좋은 붉은 글씨를 안 봐도 되겠네요!

회사에서 후배 녀석이, 벤츠(BMW 였던것 같기도 합니다) 컨셉트 카 사진을 보면서 곡선이 어떻게 이렇게 멋질 수가 있냐, 정말 갖고 싶다, 과장님 이거 사줘요 등등 갖은 오도방정을 떱니다.

그런 모습을 보니 문득 소프트웨어 설계/개발도 그런 눈에 보이고 손에 잡히는 모양으로 나타난다면 저 녀석이 참 재미있게 일하겠구나 싶은 생각이 듭니다.

'이야~ 이거 설계가 아주 매끈한데? 이 곡선을 봐~ 끝내주는구만!' '어~ 거기는 좀 더 깎아야겠는데~' 같은 식으로 대화할 수 있으면 재미있지 않겠어? 했다가 뭐든지 개발에 갖다붙인다고 핀잔만 벌었습니다.

저도 능력있는 설계자, 흔한 외래어로 아키텍트의 능력을 갖고 싶은 개발자 중의 한 명이지만 아직 어디가서 설계의 설 자도 내밀만한 정도도 못됩니다.

혹시 아키텍트로서의 능력을 각성하게되면 소프트웨어 설계가 마치 실체인 것처럼 머리속에 선명하게 떠오르게 되는 것은 아닐까 하는 공상도 해봅니다. 영화 인셉션에 나오는 장면들처럼요.

iPhone 에서 작성된 글입니다.

일단 iPad를 iOS 4.3 beta 2 로 업그레이드 해야 되겠죠.

개발자 사이트에서 iPad 용 iOS 4.3 beta 2 DMG 파일을 받습니다. 700MB 가 좀 안되는 정도의 크기입니다. 받는 동안 iPad에서 구매한 항목도 iTunes로 전송해주고, 백업도 해 둡니다. 언제나 백업은 필수죠.

다운로드가 끝나면 DMG를 더블클릭해서 마운트하면 ipsw 파일이 하나 들어있습니다.

iPad를 USB로 연결해놓고 iTunes 에서 복원을 하는데, option 키를 누른 채로 복원 버튼을 눌러줍니다. 그러면 파일 선택창이 뜹니다.

아까 마운트 한 DMG 파일에 들어있는 ipsw 파일을 선택하면 이후로는 기다리기만 하면 됩니다.

이전에 4.1에서 4.2로 업데이트할 때에는 업데이트 후에 앱들도 다 복원이 되었는데, 이번에는 데이터와 설정만 복원이 되고 앱은 복원이 되지 않았습니다. 응용프로그램만 iTunes를 통해서 다시 동기화를 시켜주니 이전의 데이터들이 다 남아 있어서 사용할 수 있게 되었습니다. (아직 다른 앱들은 괜찮은데 트위터 공식 앱은 글쓰기를 누르면 죽어버리는군요 ㅜ.ㅜ)

테더링을 해 봅니다!

일단 아이폰에서 테더링을 켭니다. 테더링을 꺼놓고 블루투스부터 연결하려고 했더니 서로 연결이 안되었습니다. (아이폰은 iOS 4.2 입니다)

그리고 아이패드에서 블루투스를 켜고 아이폰과 연결을 하면 일반 노트북으로 블루투스 테더링 쓰는 것과 동일하게, 아이폰 화면 상단은 파란 막대가 생기고 아이패드에서 테더링을 이용한 인터넷이 됩니다.

베타의 문제

제가 경험한 것은 두 가지입니다.

일단 위에서 말씀드린 것처럼 트위터 공식 앱이 글쓰기 버튼을 누르면 종료되어 버리는 것이 있습니다.

그리고 아이패드 상에서 앱 아이콘 배치(폴더 조정 등)한 것이 동기화를 해도 iTunes에는 반영이 되지 않아서, 동기화할 때마다 iTunes 쪽의 배치로 돌아가버리는다는 점 정도입니다.

지난 번 포스트에 이어지는 Xinics 개발부 블로그의 Objective-C 관련 포스트입니다. "여러 개의 인자를 받는 메소드".