이번은 chrono의 clock 클래스에 대해서 간단하게 설명 하겠습니다.

앞의 글들을 보신 분 들은 아시겠지만 이미 clock 클래스를 사용하고 있었습니다.

다만 저는 현재까지는 system_clock 이라는 클래스만을 사용하고 있었습니다.

chrono에는 system_clock뿐만 아닌 steady_clock과 high_resolution_clock이 있습니다.

system_clock는 가장 일반적으로 사용하는 것으로 시스템 시간을 표현하기 위한 시간입니다.

그리고 C 런타임의 time_t와 호환성을 가지고 있습니다.

멤버 중에 to_time_t와 from_time_t가 있는데 이름을 보면 알 수 있듯이

to_time_t는 system_clock::time_point를 time_t로 변환하고,

from_time_t는 time_t를 system_clock::time_point로 변환 합니다.

steady_clock은 물리적인 시간처럼 결코 역행하지 않는 시간을 나타내기 위한 시간입니다.

이 말은 steady_clock 이외의 clock 클래스는 time_point를 얻은 후 os에서 날짜를 과거를 되돌린 후 time_point을 얻으면 앞에 얻은 시간보다 과거의 시간이 얻어지는데 steady_clock에서는 절대 그렇지 않습니다. 그래서 시간의 흐름이 바뀌지 않는 시간을 얻고 싶을 때는 steady_clock을 사용합니다.

high_resolution_clock는 해당 플랫폼(Windows 또는 Linux 등)에서 가장 짧은 단위의 시간입니다.

이 클래스는 system_clock나 steady_clock의 다른 별칭으로 정의되기도 합니다.

보통 프로그래밍에서 아주 고해상도의 시간 단위가 아닌 경우 대부분 GetTickCount() 함수를 사용했는데(Windows에서) 앞으로는 더 간단하고 다양한 표현 방법으로 시간을 다룰 수 있는 chrono를 꼭 사용해 보시기 바랍니다^^

<예제.2>에서 보았듯이 chrono는 다양한 정밀도 타입으로 시간을 표시할 수 있습니다.

그리고 각 시간 정밀도 타입 별로 생성할 때 미리 값을 설정할 수 있습니다.

또한 이 시간 타입을 서로 연산할 수도 있습니다.

물론 다른 시간 타입을 연산할 수도 있습니다

다른 시간 타입을 연산할 때 주의할 점이 있습니다. 아래처럼

의 경우는 초와 밀리초라는 서로 다른 타입을 더하지만 값을 저장하는 타입이 밀리초이기 때문에 잃어버리는 값이 발생하지 않으므로 연산에 문제가 없습니다.

그러나 아래와 같이

로 하는 경우는 밀리초 부분을 잃어버리게 되기 때문에 컴파일 에러가 발생합니다.

이런 경우는 명시적으로 형 변환을 시켜줘야 합니다.

< 예제. 3 >

본 글을 월간 마이크로소프트 2012년 5월호 특집 기사로 다루어진 내용입니다. Visual Studio 11이 Visual Studio 2012로 변경됨에 따라 본문의 내용을 일부 수정하였습니다.

본 글 이외에 Visual Studio 팀원의 강보람 MVP님의 "Welcome to Metro User Interface" 컬럼과 남정현 MVP님의 "Windows Server 8 미리 보기" 컬럼은 필자의 블로그에 기재하지 않은 점 또한 참고하기 바라며, 저작자의 동의하에 추후에 공개가 될 수 있습니다.

시대가 바뀌면서 Windows도 전통적인 모습에서 벗어나서 새로운 흐름을 만들고자 하는 노력이 시작된 것 같다. 물론 기존의 데스크 탑은 여전히 널리 사용될 것이다. 일상적인 업무에서 사용하는 응용 프로그램이 굳이 메트로 사용자 인터페이스 형태를 띌 필요는 전혀 없을 테니 말이다. 그리고 앞으로도 계속해서 기존의 데스크 탑을 타겟으로 하는 윈폼이나, WPF의 개발도 지속될 것이다. 하지만, 새로운 기회는 작은 틈에서 나오는 것이니 이 틈새를 잘 이해하기 위해서는 Windows 8의 메트로 환경을 잘 이해할 필요가 있다.

Windows 8과 Visual Studio 2012은 그야말로 N스크린에 감히 필수적인 환경이라고 말하고 싶다. 그 어떤 플랫폼도 데스크 탑과 테블릿, 모바일 등의 모든 기기와 환경 모두를 지원하는 것은 매우 어려운 일이다. 일반 사용자가 기기마다 사용하는 용도와 스타일이 다르고, 모바일 기기마다 해상도와 특징이 다르기 때문이기도 하지만, 하나의 개발 도구로 모든 상황을 대응할 수 있는 통합 개발 도구가 없는 것도 한 몫을 한다. 아니라고 말하는 독자도 있겠지만, 필자는 데스크 탑 환경까지 확장하는 N스크린을 말하는 것이고, 모든 N개의 스크린에서 똑같은 사용자 경험을 제공하는 것을 말한다. 이런 관점에서 Windows 8과 Visual Studio 2012은 그 해답을 제시하고 있으며, 충분히 가치 있고, 도전해 볼만하다. 이런 이유로 벌써부터 필자는 매우 흥분이 된다.

그리고 이 글에서 모두 소개하기는 어려웠지만, Windows Server 8은 그 동안의 Windows 운영 체제가 보여주었던 정적인 모습을 탈피하여 대규모 데이터 센터가 아닌 비용 문제 때문에 고민이 많은 수 많은 중소 규모의 IT 인프라에서도 효율적으로 시스템을 운영하고 애플리케이션 개발자들이 핵심에만 접근할 수 있도록 도와줄 방법을 제공하고 있다. 또한 메트로 스타일의 앱은 단순히 사용자 인터페이스에 관한 새로운 접근일 뿐만 아니라 데스크톱 가상화나 서버 관리자를 위한 새로운 종류의 서비스로 자리잡을 수 있다. 여전히 Charm Bar의 기능은 유용하게 사용할 수 있으며, Application Contract를 정확하게 지원하는 서버용 메트로 앱을 만들어 서버 관리자의 일을 덜어내거나 전혀 새로운 경험의 터치 기반 KIOSK를 손쉽게 만들 수도 있을 것이다. 이것은 전적으로 여러분의 선택에 달려있는 일이 될 것이다. 더 나아가서, Windows Server 8의 여러 기술들이 각종 호스팅 환경은 물론 Windows Azure나 Amazon과 같은 Public Cloud Computing 환경에도 전면적으로 도입이 된다면 더 멋지고 유용한 서비스들이 대거 등장하지 않겠는가 하는 것이 개인적인 생각이다.

참고 자료

• IIS 8에 대한 자세한 정보는 아래에서 확인하기 바란다.
• IIS 8에서 사용하는 웹 소켓에 대한 정보는 아래에서 확인하기 바란다.
  http://www.paulbatum.com/2011/09/getting-started-with-websockets-in.html
• APPX 패키지 관리 명령어에 대한 자세한 정보는 아래의 Technet 웹 사이트에서 확인할 수 있다.
  http://technet.microsoft.com/en-us/library/hh856045.aspx
• Windows Server 8에 대한 일반적인 새로운 변경 사항들은 여기서 확인하기 바란다.
  http://www.microsoft.com/en-us/server-cloud/windows-server/v8-default.aspx
• DISM에 관련된 자세한 정보는 아래의 Technet 웹 사이트에서 확인하기 바란다.
  http://technet.microsoft.com/en-us/library/hh825176.aspx
• 메트로 스타일 앱의 Reverse Engineering 가능성 및 대비책에 대한 글은 개발자인 경우 특별히 읽어볼 것을 권한다.
  http://justinangel.net/ReverseEngineerWin8Apps
• PowerShell 3.0에 대한 자세한 정보는 아래에서 확인하기 바란다.
  http://www.techrepublic.com/blog/networking/powershell-3-takes-scripting-to-new-heights/5204

본 글을 월간 마이크로소프트 2012년 5월호 특집 기사로 다루어진 내용입니다. Visual Studio 11이 Visual Studio 2012로 변경됨에 따라 본문의 내용을 일부 수정하였습니다. 그리고 현재 필자는 NCSOFT에 재직하지 않음을 참고하기 바랍니다.

엄준일 – 현재 NCSOFT에 재직 중이며, Microsoft ALM MVP와 한국 Visual Studio 팀과 블로그를 운영하고 있다.. 주로 .NET 기술을 전파하고 있고, 마이크로소프트가 지향하는 소프트웨어 개발 프로세스와 통합 및 테스팅 분야를 4년 동안 공부해왔다. 그 외에 CodePlex 오픈 소스 사이트를 통해 프레임워크, 툴 그리고 라이브러리 등을 공개하여 운영 중이다.

C++ 매트로 앱 개발 준비 사항

C++ 매트로 앱을 개발하기 위해 C++ 개발자는 당장 개발하기 앞서 몇 가지 숙지해야 할 지식과 개념들이 있다. 그리 어려운 것들은 아니지만, 이것을 모르고 접근하려고 하면 어디서부터 시작해야 할지 매우 혼란스러울 것이다. 필자는 과거에 C와 PASCAL을 주로 사용하였고, PC통신이라는 커뮤니케이션을 통해 여러 가지 액션 게임과 대전 게임, 어드벤처 게임을 개발하여 공개해 본 적은 있으나, 최근에 사용되는 C++과 DirectX로 개발해 본 경험은 전무하다. 대신 C라는 언어와 윈도우8이라는 공통 분모를 바탕으로 최대한 C++ 개발자에게 매트로 앱을 쉽게 개발하기 위해 설명할 것이다.

C++/CX 란?

첫 번째 준비사항은, C++ 매트로 앱 개발의 위해 C++/CX를 이해해야 한다. C++/CX는 C++ Components Extension(C++ 컴포넌트 확장)이라는 의미로 그 문법은 C++/CLI와 매우 흡사하다. C++/CLI의 대부분은 .NET의 MSIL 형태의 목적 파일로 컴파일 되기 때문에, C++/CLI 응용 프로그램이 동작하기 위해서는 .NET Framework가 설치가 되어야 했었다. 이는 곧, C++/CLI의 gcnew 객체는 .NET 가비지컬렉션의 대상이 되기 때문에 .NET에 매우 가까운 구조였다. 반면, C++/CX은 간단하게 정의하자면 간결한 COM 프로그래밍 언어이다. 그 문법이 C++/CLI와 같지만, 완벽하게 네이티브 형태로 컴파일 된다. 이 말은 즉, .NET Framework이 필요가 없고, .NET 가비지컬렉션의 대상이 되지도 않는다.

앱 개발에 필수 런타임인 WinRT(Windows Runtime)를 이용하여 구현을 하기 위해선 IInspectable 인터페이스를 구현해야 한다. COM 프로그래밍에 직간접적으로 IUnknown 인터페이스를 구현하는 것과 같다. 왜냐하면 IInspectable 인터페이스는 IUnknwon 인터페이스를 상속하기 때문이다.

IInspectable 인터페이스는 곧 COM 개념과 같다. 컴포넌트를 다양한 언어와 공유하고 통합할 수 있는데 WinRT 프로그래밍에서 C#, VB.NET, 그리고 JavaScript에서 IInspectable을 구현하는 객체를 사용할 수 있게 된다. (단, IInspectable 인터페이스는 컴파일러에 의해 구현될 수 있다)

Code 1 IInspectable 인터페이스 정의

COM 프로그래밍 중 가장 빈번하게 사용되는 것 중 하나가 참조 카운팅인데, ^ 기호로 참조 카운팅을 관리하는 개체를 ref new로 인스턴스를 생성하면 더 이상 귀찮은 AddRef와 Release메서드를 호출해 줄 필요가 없다. 예를 들어, Platform::WeakReference 등을 이용하여 생성된 객체에 대해 수명 관리를 위임할 수 있는 방법들이 제공된다.

정리해보면, WRL(Windows Runtime Library)가 C#, VB.NET, JavaScript로 개발할 수 있는 환경을 제공하는 것이 바로 COM이며, 이를 쉽게 개발할 수 있는 언어가 C++/CX인 것이다.

프로퍼티(Property) 사용

C++/CX는 프로퍼티를 사용할 수 있는 키워드를 제공한다. C++/CX 프로퍼티는 .NET 프로퍼티와 내부적으로 똑같이 동작한다. 이 프로퍼티는 컴파일 시에 get/set 메서드를 자동으로 생성해 준다. 프로퍼티는 읽기 전용/쓰기 전용, 그리고 이 두 가지 모두를 지원하도록 구현할 수 있다.

이 프로퍼티는 매트로 앱을 개발하면서 상당히 자주 만나게 될 것이다. 왜냐하면 XAML과 함께 앱을 구현하면서 바인딩(Binding) 개념에 프로퍼티 구현이 필수적이기 때문이다. 그래서 XAML 바인딩에서 INotifyPropertyChanged 인터페이스를 구현하여 데이터 모델과 바인딩된 데이터간에 데이터 변경에 대해 알려줌으로써 1-way 또는 2-ways 바인딩을 사용한다.

Code 2 C++/CX 프로퍼티

이 프로퍼티는 내부적으로 생성되는 get/set 매서드를 사용하는 것이 아니라 선언된 프로퍼티를 마치 맴버 변수처럼 사용이 가능하다. 일반적인 C++ 에서는 get/set 메서드를 구현하는 방식으로 person->setName(L"Junil Um"); 이런 코드를 더 이상 사용하지 않는다.

아래의 코드와 같이 프로퍼티로 선언한 이름으로 직접 엑세스할 수 있다.

Person^ person = ref new Person("Junil Um");

person->Age = 20;

필자는 매크로를 사용하여 좀 더 빠르고 쉽게 프로퍼티를 선언하여 사용하는 방식을 권하고 싶다. 아래의 코드는 프로퍼티의 get 또는 set, get/set 을 매크로로 대체한 것이다.

안전한 포인터 사용, 대리자(Delegate)

포인터 함수는 C++에서 흔히 사용되지만, WinRT 프로그래밍에서는 직접적인 포인터 연산이 그리 좋은 코드는 아닐 수 있다. 이유는 간단하다. WinRT APIs (내장 라이브러리)들이 인자 값으로 포인터가 아닌 대리자(Delegate)를 즐겨 전달 받는다. 그리고 이벤트(Events) 프로그래밍에서 대리자를 공통적으로 사용한다.

Code 3 함수 포인터

.NET 에서는 대리자(Delegate)를 안전한 포인터 함수라고 정의한다. 포인터 함수를 사용하든, 대리자를 사용하든 결과는 똑같지만 이왕이면 안전하게 제어할 수 있는 대리자를 사용하라는 것이다. 사실, .NET 에서 대리자는 일반적인 클래스(Class)와 똑같이 취급한다. 대리자는 컴파일이 되면 일반적인 클래스로 정의되기 때문이다.

어쨌든 위의 포인터 함수를 대리자로 바꾸어보면 다음과 같다.

Code 4 C++/CX 대리자

C++/CX 매트로 만들기 첫 걸음

이제 매트로 앱 코드를 작성하고 이해하기 위한 어느 정도의 준비는 된 것 같다. 매트로 앱은 처음 앱의 처음 진입점이 App클래스의 OnLaunched 메서드이다.

Code 5 앱 진입점인 App 클래스

위의 코드의 LaunchActivatedEventArgs 인자는 main 함수의 인자 값이라고 생각해도 좋다. 단지 다른 점을 찾는다면 LaunchActivatedEventArgs 객체는 COM Proxy 개체로써, 앱 실행시 인자 값 등을 전달 받을 수 있다. .

이곳에서 앱의 초기화를 수행한 후에 Frame->Navigate 메서드로 사용자 인터페이스를 가지고 있는 화면으로 이동한다. C#,VB.NET 그리고 C++ 매트로 앱은 XAML(Extensible Application Markup Language)을 이용한다. 처음 .NET Framework 3.0에서 WPF 응용 프로그램에서 XAML을 주로 사용하였으나, .NET Framework 4.0에 와서는 별도의 구성요소로 분리가 되었고, 현 버전에서는 완전히 독립된 컴포넌트로 구성되었다. XML은 언어의 분류상 객체지향언어로 구분하게 되는데 XAML은 객체지향언어와 상호작용이 가능하여 그 확장의 가능성이 무한대로 볼 수 있다.

매트로 앱과 친해지기 위해서는 C++/CX도 이해해야겠지만, XAML도 항상 벗처럼 삼아야 한다. XML 프로그래밍에 익숙한 독자라면 XAML이 어렵지 않을 것이다. XML 프로그래밍은 책 몇 권의 분량으로도 모두 담지 못할 것이다. 그리고 XAML 또한 책 한 권 분량 이상으로 그 내용이 방대하므로 더 자세한 내용은 MSDN을 통해 천천히 익히길 바란다.

Figure 1 Blend for Visual Studio 2012

XAML을 처음부터 거부감을 느낄 필요는 없다. 당장은 앱을 만들기 위해 디자인을 해야 하는데, Blend for Visual Studio 2012 (과거 Expression Blend) 라는 디자인 도구가 있다. XAML은 이 도구를 이용하여 디자인을 하면 개발자도 쉽게 사용자 인터페이스를 완성할 수 있다.

지면으로 모든 것을 설명하지 못하니, 다음의 링크를 반드시 확인하기 바란다.

http://msdn.microsoft.com/en-us/windows/apps/br229516

이 링크에서 매트로 앱을 만들기 위한 개발 도구 및 SDK와 샘플 앱을 C#, C++, JavaScript로 구현해 놓았고, 마이크로소프트가 제공하는 품질 좋은 디자인 파일도 있다.

본 글을 월간 마이크로소프트 2012년 5월호 특집 기사로 다루어진 내용입니다. Visual Studio 11이 Visual Studio 2012로 변경됨에 따라 본문의 내용을 일부 수정하였습니다. 그리고 현재 필자는 NCSOFT에 재직하지 않음을 참고하기 바랍니다.

엄준일 – 현재 NCSOFT에 재직 중이며, Microsoft ALM MVP와 한국 Visual Studio 팀과 블로그를 운영하고 있다.. 주로 .NET 기술을 전파하고 있고, 마이크로소프트가 지향하는 소프트웨어 개발 프로세스와 통합 및 테스팅 분야를 4년 동안 공부해왔다. 그 외에 CodePlex 오픈 소스 사이트를 통해 프레임워크, 툴 그리고 라이브러리 등을 공개하여 운영 중이다.

성큼 다가온 Visual Studio 2012

Microsoft의 대표적인 통합 개발 도구인 Visual Studio 2012의 성장세가 무척 빠르다. 지난 10년전 .NET 플랫폼과 함께 대표적인 개발 도구인 Visual Studio.NET (2003버전)를 내놓았다. 그 때의 시간이 바로 엊그제 같은데 그 이후 Visual Studio 2005, 2008, 2010을 지나 Visual Studio 2012베타 버전을 필자가 사용하고 있으니, 짧은 10년동안 Microsoft를 비롯하여 개발 언어, 개발 툴, 이 모든 것이 굉장히 많이 변해 왔음을 새삼 다시 느껴진다. 이제 Windows 8라는 새로운 운영체제가 기다리고 있다. 그리고 이를 빛내줄 Visual Studio 2012.

성큼 다가온 Visual Studio 2012과 그 발자취

Visual Studio 2012를 먼저 논하기 전에 Visual Studio가 어떤 발자취를 남기며 발전해 왔는지 간단하게 살펴보는 것도 독자들이 Visual Studio 2012를 이해할 수 있는 좋은 방법이라고 생각한다. 물론 짧고 간단하게 모든 것을 설명할 수는 없지만, 전반적인 특징만으로 그 동안 개발 트랜드가 어떻게 바뀌었고, 시장의 요구 사항이 어떻게 변화하여 왔는지 한 눈에 알 수 있는 가장 좋은 방법이라고 생각한다.

Microsoft의 첫 번째 진정한 통합 제품으로 평가 받는 제품이 Visual Studio.NET (2003버전)이다. Microsoft의 전략적인 언어인 C# 1.0과 VB.NET(v7.0)이 .NET 개발의 대표적인 언어가 되었다. 기존의 VB를 세련된 객체지향 언어로 탈바꿈하면서 이전의 VB개발자들에게 .NET 개발의 문턱을 낮출 수 있는 매우 좋은 사례이기도 하다. (단, Visual Studio 2002는 논외로 하겠다)

이 이전의 개발도구는 하나의 도구에서는 하나의 언어로만 개발을 할 수 있었고, 개발 툴 역시 그 언어에 매우 종속적이고, 다른 언어로 전환하려면 이전의 개발 도구와 개발 경험 역시 많은 부분을 새로 습득해야 했다. 특히 J# 이라고 하는 Java 언어와 라이브러리를 제공하였는데, Java 개발자들을 .NET 플랫폼 안으로 끌어안기 위한 매우 독특한 사례이기도 하다. 실제로 J#은 웬만한 Java 소스 코드를 변경 없이 .NET 목적 파일로 컴파일 할 수 있었다.

Visual Studio는 하나의 개발 도구를 통해 여러 가지 언어를 선택하여 웹 응용 프로그램, 윈도우 응용 프로그램, 모바일 개발, XML, XML 웹 서비스를 개발을 통합하고, 여기에 포함되는 .NET Framework 1.0은 응용 프로그램을 빌드하고 실행하는 구성요소로서, ADO.NET, ASP.NET, Windows Forms 등을 포함하는 .NET Framework 클래스 라이브러리와 CLR(Common Language Runtime-공용 언어 런타임)을 제공, 이 CLR 을 통해 공통된 API 집합을 만들어 다양한 언어간의 상속, 오류 처리, 디버깅이 가능하며 개발자들은 사용하려는 언어를 자유롭게 선택할 수 있게 되었다.

이 후, Windows Server 2003 제품에 표준으로 탑재하여 .NET Framework의 확산에 큰 공을 이루게 되었고, 실제로 엔터프라이즈 시장에서 이 버전을 기준으로 많은 기업용 시스템에 도입이 되었다. 현재까지도 이 버전을 기준으로 운영이 되는 기업용 시스템이 상당수 존재하고 있을 정도이다.

때는 2005년. Visual Studio 2005버전은 파격 그 자체다. 여기에 포함된 런타임인 ..NET Framework 2.0은 이전 .NET Framework 1.x에 사용된 코드를 대부분 갈아 엎었을 정도이다. .NET Framework의 뼛속까지 변신한 것이다. ASP.NET 2.0, ADO.NET 2.0, Windows Forms 2.0, C# 2.0 과 같이 '~2.0' 이라는 버전 번호를 붙였고, 많은 기능이 보완되고 확장되었다. .NET Framework 2.0 의 주요 컴포넌트들은 더 이상 .NET Framework 1.1 에 의존하지 않게 되었으며, .NET Framework 2.0 은 .NET Framework 3.5 SP1 까지 .NET Framework의 모태가 된다.

모든 것이 생소할 정도로 많은 변신이 있었는데, 그 중에서 C#과 VB.NET 언어가 대표적이다. Boxing(박싱), Unboxing(언박싱)의 반복적인 캐스팅(Casting) 의 비효율을 개선하고, 보다 객체지향적인 코드 품질을 생산할 수 있는 제네릭(Generic)이 등장하였다. 이와 함께 .NET Framework 클래스 라이브러리에 다수의 제네릭(Generic) 클래스가 추가되었다. 개발 툴도 많은 변화가 있었는데, IDE 자체의 외관도 많이 변했고, 개발 툴의 내부적인 코드에서 변화가 왔고 다양한 내부 인터페이스가 추가되었다. Visual Studio의 솔루션 탐색기에서 흔히 사용하는 '솔루션 폴더'도 이때 등장하였다.

그리고, 이 제품의 버전부터 Visual Studio Team Suite + Team Foundation Server 의 제품을 조합하여 Visual Studio Team System(VSTS) 라는 새로운 개발 패러다임을 .NET 에서도 지원하게 되었다. VSTS 를 통해 ALM(Application Lifecycle Management-애플케이션 수명 주기 관리) 을 수행할 수 있게 되었으며, IT 조직의 비지니스 전반의 생산성을 향상 시키고, 사람과 개발 조직의 변화를 가져다 주는 시초가 되었다.

.NET Framework 3.0은 새로운 개발 도구와 출시되지 않았다. 2005년 중순 Windows Vista 운영체제가 출시되면서 이에 대응하는 라이브러리가 포함이 되었다. 함께 새로운 기술도 대거 포함이 되었는데, 그 중에서 대표적으로 꼽으라고 하면 WPF와 WCF이다. XAML(Extensible Application Markup Language) 과 함께 WPF 의 출연으로 UX(User Experience) 의 시대 흐름에 진입하게 되었다. 또한, WCF는 여러 가지의 분산 통신 기술이 통합되었다. 이전의 Remoting, XML Web Services, MSMQ 등이 하나의 WCF 컴포넌트에서 제공하게 됨으로써 Messaging Model 기반으로 통합할 수 있게 되었다.

때는 2007년, 또 한번의 메이저 급 업데이트였다 언어적으로 LINQ라는 새로운 녀석 때문이다. LINQ(Language Integrated Query) 라는 이름에서 알 수 있듯이 익숙한 SQL Query 문법과 유사하여 객체 탐색에 있어 효율성이 매우 높아졌고, 그 성능도 일일이 손으로 짠 코드보다 더 빠른 경우가 있다. 이 LINQ의 기반이 되는 람다식(Lambda Expression), 익명 타입(Anonymous Type), 확장 메서드(Extension Methods)의 언어적인 새로운 스팩이 한데 아우러져 LINQ를 구성한다. XML객체, DataSet, 파일 시스템, 컬렉션 등 모든 대상이 LINQ 쿼리식의 대상이 된다. 이에 영향을 받아 JavaScript와 Java 언어에 영향을 주어 LINQ와 유사한 프레임워크가 등장하였지만, .NET 과 같이 언어적으로 통합이 되지 않았다. 마치 Method Chaining 패턴을 이용한 라이브러리로 분류된다.

이 밖에 정말 헤아릴 수 없을 정도의 많은 진보가 있었다. 개발 도구와 개발 언어, 그리고 .NET 플랫폼의 기술이 발전한다는 것은 분명 매우 좋은 일이겠지만 아마 이 시기부터 많은 .NET 개발자들이 Microsoft의 기술 발전을 따라가기 벅차했었다.

2010년에 이르러, Visual Studio 2010버전이 출시되었다. 너무 빠른 .NET 기술의 발전의 탓일까, 이 때는 언어와 .NET Framework보다는 Visual Studio라는 개발 툴에 가장 초점이 맞추어졌다. 그 중 핵심 키워드라고 할 수 있는 것 3가지는 "시각화", "디버깅", "프로세스" 일 것이다. (필자의 의견이므로 Microsoft가 추구했던 것과는 다를 수 있다.) 이 세 가지의 핵심 키워드는 시각화, 협업에 있어 코드의 이해를 좀 더 쉽게, 그리고 복잡한 데이터를 한 눈에 알 기 쉽게… 디버깅-디버깅 시 데이터의 수집이 혁신적으로 발전하였고, 물리적으로 분리된 티어(Tier)간에 데이터 수집… 프로세스, 애자일을 강조하고 애자일한 통합 프로세스를 개발 툴에 제공.

.NET Framework 4.0은 .NET Framework 2.0기반이 아닌 새로운 프레임워크로 구성되었고, 멀티코어 처리를 위해 강력한 병렬 처리 라이브러리(Parallel Libraries)가 있다. 또, 동적 언어 런타임(Dynamic Language Runtime)으로 정적 형식과 동적 형식의 경계를 허물었으며, 루비(Ruby), Lisp, JavaScript, 파이썬(Phython), PHP와 같은 동적 언어와 상호 운용이 가능하다. 예를 들자면, C# 언어로 파이썬 개체와 상호 연동이 가능하다는 것이다.

Visual Studio 2012과 함께 매트로 앱 개발

Visual Studio 2012의 가장 큰 핵심은 바로 Windows 8 운영체제이다. Windows 8은 매트로 응용프로그램이라는 새로운 환경과 WinRT(Windows Runtime)인 새로운 런타임을 제공한다 그리고 Visual Studio 2012는 Windows 8 운영체제에 가장 최적화된 개발 툴이다. 독자들은 또 새로운 것을 배워야 하나라고 한숨을 쉴 수도 있을 것이다. 하지만 섣부른 독자들의 판단은 잠시 후에 하기 바란다. 왜냐하면 Windows 8 개발은 새로운 환경이면서도 새로운 환경이 아닐 수도 있다. Windows 8 운영체제를 사용하고 WinRT APIs 집합을 사용하는 것 이외에는 아무것도 변한 것이 없기 때문이다. 단지 바뀐 것은 여기에서 개발된 응용 프로그램은 데스크탑 컴퓨터, 테블릿, 모바일 환경 모두 실행되고 배포할 수 있다는 것이다.

최근 개발 환경을 엿보자면 C++을 사용하는 네이티브 개발과, NET에서 지원하는 C#과 같은 관리 언어, 그리고 웹 개발에 필요한 HTML과 JavaScript, 이 중에 단 한가지 기술 영역만 있으면 Windows 8 매트로 응용 프로그램 개발 준비는 끝이라는 것이다. 우리가 흔히 사용하는 스마트 폰을 보면 알 수 있듯이, 개발자는 단지 '위치 정보', '화면의 표현 방법', '데이터 연동', 그리고 스마트 폰을 가로로 볼 때와 세로로 볼 때와 같은 일상적인 기능을 제공하는 APIs를 익히기만 하면 된다. 기존에 Visual Studio를 사용하여 개발해 본 독자라면 그 만큼 진입 장벽이 낮다.

윈도우 폰7 개발처럼 테블릿 시뮬레이터가 제공이 된다. Windows 8 테블릿이 지원하는 대부분의 모든 기능을 이 시뮬레이터에서 테스트를 해 볼 수 있다. 윈도우 폰7 개발처럼 반드시 시뮬레이터가 필요한 것은 아니다. 실제 시뮬레이션이 필요 없다면 곧바로 로컬 데스크 탑에서 매트로 앱을 실행해 볼 수 있다.

Figure 1 Visual Studio 2012 매트로 앱 실행 및 디버깅

더불어 Visual Studio에서 제공하던 성능 측정 도구와 코드 정적 검사를 매트로 앱 개발 환경에서도 그대로 이용할 수 있다. 이는 곧 Visual Studio 2012이 Windows 8 개발에 가장 최적화가 되었다는 의미가 된다.

Figure 3 매트로 앱 성능 측정 및 진단

간략하게 나마 Visual Studio 2012과 Windows 8 개발에 대해 살펴보았다. 필자가 얘기한 것처럼 개발자에게 있어 새로운 환경이지만, 반대로 전혀 새롭지 않기도 하다. Visual Studio로 간단한 앱을 만들 수 있는 실력이라면 곧바로 Windows 8 매트로 앱을 개발할 수 있을 정도로 진입 장벽이 낮다. 물론, 좀 더 기술적이거나 독창적이고 예쁜 앱을 만드는 것은 더 많은 노력이 필요하다. 단지, 앱 개발자는 자신만의 앱 개발에만 집중하면 된다.

Figure 4 Windows 8 개발에서 배포까지

Visual Studio 2012과 함께 매트로 환경의 게임 개발

데스크 탑과 테블릿, 그리고 모바일 앱 중에서 단연 게임이 빠질 수 없다. 매트로 환경에서 게임 개발은 아직 시장이 포화되지 않은 장르이다. 그 만큼 게임 개발자에게 있어 매트로 환경에서 게임 개발은 매우 유혹적이기도 하다. 더 반가운 소식은 매트로 게임 개발에 필요한 지식은 게임 개발자에게 익숙한 C++언어와 DirectX다. DirectX를 이용하여 2D, 3D 게임을 개발할 수 있다.

얼마 전까지만 해도 Microsoft가 전략적으로 게임 개발을 지원하던 프레임워크인 XNA를 매트로 게임 개발에 지원하지 않는다. 대신 기존 게임 개발자에게 기존 개발 환경을 그대로 이어갈 수 있는 DirectX를 선택한 것이다.

chrono는 C++11에서 새로 추가된 시간 라이브러리입니다. 기존의 C 런타임에서 제공하는 time 함수에 비해서 다양한 기능이 있고, 사용이 쉽고 정밀도는 훨씬 높습니다. time 함수는 초 단위의 값만 측정할 수 있는 것에 비해 chrono는 나노 밀리 초 단위도 측정할 수 있습니다.

현재의 C++(C++03)에서는 초 단위보다 더 정밀한 단위로 시간을 측정할 때는 OS에서 제공하는 API를 사용해야 했는데 chrono를 사용하면 OS 독립적으로 높은 단위의 시간을 측정할 수 있습니다.

VC10에서는 chrono가 들어가지 않았지만 이번 VC11에서 chrono는 STL에 들어갔습니다. 만약 VC11을 사용하지 못하는 경우라면 Boost 라이브러리를 사용하면 사용할 수 있습니다.

chrono를 사용하면 특정 시간 구간에 걸린 시간을 초, 밀리 초, 나노 초 단위로 얻을 수 있으며 또 시간끼리 연산을 할 수 있습니다

chrono 사용 방법

chrono를 사용하기 위해서는 아래의 헤더 파일을 추가합니다.

chrono에 대한 자세한 설명에 앞서 어떤 기능인지 좀 더 쉽게 알 수 있도록 예제를 하나 보여드리겠습니다. 아래의 예제는 어떤 함수의 성능을 측정하기 위해서 chrono를 사용했습니다.

< 예제. 1 >

< 실행 결과 >

<예제.1>에서는 std::chrono::system_clock::now()을 사용하여 현재 시간을 얻습니다.

여기서 time_point 타입은 시간 상의 한 축을 뜻합니다.

이후 Test() 함수를 실행한 후 다시 현재 시간을 얻은 후 Test()를 시작하기 전에 저장한 현지 시간을 빼면 Test()를 수행하는 걸린 시간을 얻을 수 있습니다.

* std::chrono::system_clock::now()에 의해서 얻는 시간의 초기 시간은 1970년 입니다.

시간 단위

chrono는 경과 시간을 계산할 때 다양한 시간 타입으로 계산할 수 있습니다.

<예제.1>에서는 초 단위의 정밀도로 소수점까지 표시할 수 있었습니다.

그런데 보통은 소수점이 나오는 결과 값보다는 정수로 나오는 값을 사용하는 경우가 많을 것입니다.

chrono에서는 경과 시간을 나타내는 클래스는 duration입니다.

duration은 6개의 시간 단위를 지원합니다.

<예제.1>을 수정하여 위에 열거한 chrono의 다양한 단위를 사용하여 시간 측정을 해 보겠습니다.

< 예제. 2 >

< 실행 결과 >

unscoped enumeration과 scoped enumeration 둘 다 전방 선언을 할 수 있습니다.

아래와 같이합니다.

전방 선언을 할 때 unscoped enumeration은 타입 선언을 생략할 수 없지만 scoped enumeration은 타입 선언을 생략 할 수 있습니다.

아래 예제 코드를 보면 전방 선언을 올바르게 사용한 것과 잘못 사용한 예를 볼 수 있습니다.

< TypeDef.h >

< Character.h >

< Character.cpp >

C++11(새로운 C++ 표준의 이름)의 enum은 지금(C++03)과 다르게 두 가지의 enum이 있습니다.

바로 unscoped enumeration과 scoped enumeration 입니다.

unscoped enumeration

unscoped enumeration은 기존의 enum과 비슷한 것 이라고 생각 하면 좋을 것 같습니다.^^

unscoped enumeration은 아래와 같이 정의하고 사용합니다.

사용은 아래와 같이

 또는

scoped enumeration 

scoped enumeration은 아래와 같이 정의하고 사용합니다.

사용은 아래와 같이 합니다.

그러나 아래는 에러입니다.

scoped enumeration은 unscoped enumeration와 다르게 CHARACTER_CLASS를 생략하면 안됩니다. 즉 WARRIOR 이나 MONK는 CHARACTER_CLASS의 범위 안에 있음을 가리킵니다.

그리고 enum class 대신 enum struct을 사용해도 괜찮습니다. 또 타입을 지정하지 않으면 기본으로 int 타입이 됩니다.

형 변환

unscoped enumeration은 기존과 같이 암묵적으로 정수로 변환할 수 있습니다.

int i = WEAPON;

그러나 scoped enumeration은 명시적으로 타입 캐스팅을 해야합니다.

int i = static_cast<int>( CHARACTER_CLASS::WARRIOR);

< 예제 >

VC11의 STL 컨테이너들은 이전 버전에 비해서 크기가 작아져서 메모리를 절약할 수 있게 되었습니다. 이전 버전과 다르게 VC11부터는 데스크탑 뿐만이 아닌 테블렛이나 스마트폰의 모바일 플랫폼 개발에서도 사용되므로 메모리 절약은 적지 않은 도움이 되리라 생각합니다.

아래 표는 x86(32비트 또는 ARM)과 x64(64비트) 플랫폼에서 각 VC 버전 별로 얼마만큼의 메모리를 사용하는 잘 표시하고 있습니다.

이 표는 VC11 뿐만이 아닌 이전 버전 사용자들에게도 도움이 될 것 같습니다. 저와 같은 서버 프로그래머들은 서버 프로그램이 설정한 동접자 수에서 어느 정도의 메모리를 소비할지 어느 정도 계산하고 있어야 하는데 이 표를 보면 메모리 계산할 때 도움이 될 것입니다

표의 바이트 사이즈는 Release 버전 기준입니다. 표에서 'VC9 SP1 SCL=0'은 SCL은 _SECURE_SCL를 뜻하는 것으로 원래 SCL은 기본은 1인데, 최고 스피드를 위해서 수동으로 SCL을 0으로 설정한 것입니다. 또 VC10과 VC11에서는 기본으로 _SECURE_SCL은 0으로 되어 있습니다.

표의 출처는 MSDN입니다^^

드디어 Visual Studio 2012(이하 VS2012)의 RC판이 나왔습니다(사실 꽤 되었죠^^;). 

이번 VS의 Visual C++(이하 VC++)의 버전은 11이 됩니다.

한동안 Visual C++은 변화가 거의 없다가 VC++ 9(VS 2008)에서 변화의 조짐을 보이다가 VS 2010에서 새로운 C++ 표준인 C++11(그 당시에는 C++0x라고 부름)과 병렬 프로그래밍, 툴의 기능 강화를 통해서 이전에 비해서 큰 변화를 이루었습니다.

또 이번 VS 2012에서도 VS 2010 버전 이상으로 큰 변화가 생겼습니다. 변화는 대격변이라고 부를 수 있을 정도입니다!.

이번에는 다음과 같은 변화가 있습니다.

1. Windows 8 Metro 앱 개발

아주 큰 변화 중의 하나입니다. 정식 제품이 가을쯤에 나올 Windows 8 Metro와 Windows Phone 8용 앱을 C++을 사용하여 개발할 수 있습니다. 이것을 위해 WinRT라는 새로운 플랫폼 API와 C++/CX가 새로 생겼습니다.

2. 툴 기능

다양한 C++ 토큰들에 다양한 색을 지정.

찾을 요소를 눈에 잘 뛰게 해준다.

편의 기능이 코딩 시 멤버 선택.

인텔리센스에서 C++/CLI 지원.

코드스니펫을 이용한 고속 코딩.

3. C++11 지원

이번에는 코어 언어 기능 보다는 라이브러리 기능이 더 중심이 되었습니다. 그러나 코어 언어에서 VC++ 10에서 큰 사랑을 받은 auto에 버금가는 range-based for loop가 있습니다. 그리고 라이브러리에 Thread가 추가 되었습니다. 이번에는 공부할 것이 많습니다 ^^;

4. 컴파일러 개선

CPU 개수에 맞추어 컴파일 속도가 향상.

Auto-Vectorizer에 의한 프로그램 성능 향상.

5. 병렬 프로그래밍

기존의 병렬 라이브러리 개선.

새로운 디버깅 및 시각화 기능에 의해 쉽고 올바른 병렬 프로그래밍 진단.

GPU 병렬 프로그래밍을 위한 C++ AMP 추가.

6. 네이티브 유닛테스트 프레임웍 추가

사제가 아닌 마이크로소프트 순정의 유닛테스트 프레임웍!!!.

이렇게 VC++ 11의 새로운 기능을 정리해 보았습니다. 제가 대충 큰 것만 정리했는데도 공부할 것이 많지 않습니까?^^; 한번에 다 하면 부담되지만 조금씩 하면 충분히 공부할만한 분량입니다. 아직 정식 버전이 나오지 않았으니(가을쯤에 나온다고 합니다) 여유를 가지고 지금부터 조금씩 천천히 공부해 보죠^^

ps 1: VC++의 각 버전 별 내부 버전 번호와 코드에 정의된 버전

브랜드 버전                  내부 버전          #define _MSC_VER 버전

Visual C++ 2005            VC8                 1400

Visual C++ 2008            VC9                 1500

Visual C++ 2010            VC10                1600

Visual C++ 2012            VC11                1700

ps 2: 실행 환경

위에는 VC++11의 좋은 점만 이야기 했지만 개인적으로 걱정되는 것이 있습니다. 가장 큰 문제가 실행 환경입니다. VC++11은 Windows Vista 이상에서만 실행되고 또 VC++11을 이용해서 만든 프로그램도  Windows Vista  이상에서만 실행할 수 있습니다.

Windows 8 Metro 앱 개발을 하거나 저처럼 서버 개발을 하는 개발자에게는 큰 문제가 되지 않을 수도 있지만 클라이언트 개발자에게는 이 부분이 VC++11을 사용하는데 큰 걸림돌이 되리라 생각합니다

 => 그런데 VC++ 팀블로그를 보니 많은 고객들이 XP 지원을 요청해서 가을쯤에 업데이트를 통해서 XP도 지원해 준다고 합니다.^^ 

http://blogs.msdn.com/b/vcblog/archive/2012/06/15/10320645.aspx

이로써 큰 고민을 하나 해결 되었네요^^