Visual Studio 2010 공식 팀 블로그 @vsts2010

안녕하세요~ 조진현입니다.
얼마 전 대구에서 KGC 2011 행사가 있었습니다.
저는 그 곳에서 DirectX11 과 관련한 발표를 진행하고 왔습니다.
그래서 발표 슬라이드를 공개해 드립니다.

특히나 이번 발표 때, C++ AMP 에 대한 언급이 있었습니다.
AMP는 아래 링크에 흥배님이 자세히 설명해 주셨습니다.
http://vsts2010.net/591

빠른 시간 내에 발표 때 언급했던 C++ AMP 와 관련한 내용을
팀 블로그에 게재하도록 하겠습니다..^^

constexpr를 클래스에 사용

constexpr을 클래스에서 사용하면 클래스를 정수로 사용할 수도 있으며 메타 템플릿 프로그래밍에서는 이전에는 복잡하게 처리하던 것을 아주 간단하게 처리할 수도 있습니다. C++ 메타 템플릿 프로그래밍에 관심이 많구나 자주 사용하고 있는 분들에게는 constexpr 덕분에 프로그래밍이 한결 편해지리라 생각합니다.

아래의 코드는 Integer 이라는 클래스를 constexpr을 사용하여 정수처럼 사용 합니다.

출처 : http://cpplover.blogspot.com/2010/11/gccniconstexpr.html

또 메타 템플릿 프로그래밍에서는 아래와 같이 사용할 수도 있습니다.

출처 : http://d.hatena.ne.jp/faith_and_brave/searchdiary?word=constexpr&.submit=%B8%A1%BA%F7&type=detail

constexpr은 컴파일 할 때 결과가 이미 결정 나는 것은 컴파일 타임 때 처리를 해주어 실행 시에 불필요한 처리를 막아주고, 기존의 메타 템플릿 프로그래밍으로 까다롭게 만들었던 것을 아주 쉽게 구현할 수 있게 해줍니다.

C++11에서는 constexpr을 잘 사용하면 기존 보다 더 뛰어난 프로그래밍을 할 수 있으니 깊게 파고들 가치가 있다고 생각합니다.

constexpr는 변수, 함수, 클래스를 컴파일 타임에 정수로 사용할 수 있도록 해줍니다. 즉 상수로 취급할 수 있는 작업은 컴파일 타임에 처리하도록 할 수 있습니다.

constexpr를 변수에 사용

이것은

와 같은 의미를 가집니다.

그러나 아래와 같이는 사용할 수 없습니다.

constexpr를 함수에 사용

C++03에서는 아래의 코드는 에러가 됩니다.

GetNum 함수는 상수 5를 반환 하는 것으로 이미 컴파일 시에 반환 값을 알 수 있습니다. 그러나 컴파일러는 GetNum 이라는 함수가 정수처럼 사용할 수 있는지 알 수 없으므로 정수로 취급하지 않습니다.

위 코드는 C++11의 constexpr를 사용하면 우리가 원하는 대로 GetNum 함수를 정수로 사용할 수 있습니다.

constexpr를 함수에 사용할 때는 꼭 함수 본체는 { return expression; } 형태가 되어야만 합니다.

constexpr 변수는 비 constexpr 변수에 사용할 수 있으므로 아래와 같은 테크닉도 사용할 수 있다.

(출처) http://cpplover.blogspot.com/2010/11/gccniconstexpr.html

그리고

라는 코드는 정수 계산을 하는데 실행 시에 계산되는데 이것을 constexpr을 사용하여 컴파일 시에 계산되게 할 수 있습니다.

현재의 표준 C++에서는 부모 클래스의 특정 멤버를 오버라이드 할 때 virtual을 앞에 붙입니다.

 위의 예제와 같은 작은 코드를 만질 때는 실수를 하지 않지만 실제 일을 할 때는 크고 많은 클래스를 다루다 보면 실수를 할 수 있습니다. 위 예제의 경우 아래와 같은 실수를 할 수 있습니다.

위와 같이 실수를 하면 Derived의 foo 멤버함수는 Base의 foo 멤버함수를 오버라이드 하지 않게 됩니다. 이런 실수는 에러가 아니기 때문에 골치 아픈 삽질을 할 수도 있습니다.

이런 문제를 방지하기 위해서 override가 새로 생겼습니다.

이렇게 override를 사용하게 되면 컴파일 할 때 Base 클래스에

void foo( float i )가 없는데 오버라이드 한다고 에러를 발생시켜 줍니다.

때로는 Base 클래스의 특정 멤버함수를 Derived 클래스에서 오버라이드 하지 못하도록 막고 싶은 경우가 있을 것입니다. 이때는 final을 사용합니다.

위의 코드에서는 Base 클래스의 foo 멤버함수를 final로 오버라이드 못하도록 해 놓았기 때문에 컴파일을 하면 에러가 발생합니다.

참고

위키피디아 http://en.wikipedia.org/wiki/C%2B%2B0x

새로운 C++ 표준 작업이 언제쯤에나 끝날지 고대하고 있는 분들에게 반가운 소식이 있습니다.

드디어 C++0x 작업이 거의 마무리 되었습니다.

저번 주 수요일에 최종 국제 투표가 끝난 후 드디어 결과가 나왔는데 ‘만장 일치로 승인’이 되었습니다. 이제는 앞으로 몇 달 후에 ISO로부터 최종 발행만 기다리면 됩니다(즉 서류적인 절차만 남았습니다).

이로써 길게 길게 진행된 C++의 새로운 표준 작업은 끝나게 되어서 이제 C++11로 불리게 되었습니다( 이전에는 C++98, C++03이 있었습니다 ).

C++은 특정 회사가 주도하지 않고, 기존에 C++로 만들었던 코드가 문제 없이 동작해야 하고(표준 사양만 지켰다면), 성능과 편리성을 모두 가지려고 하니 많은 시간이 걸렸습니다.

아직 ISO에서 최종 문서가 나오지 않았고 무료로 최종 사양이 어떻게 되었는지 궁금한 분들은 http://t.co/5mjCzyJ 를 통해서 문서를 받아보기 바랍니다. 이 문서는 워킹 드래프트 3242로 ISO에서 나올 사양 문서와 거의 같을 것입니다(참고로 ISO에서 나온 문서는 유료입니다).

이제 우리는 앞으로 나올 Visual C++이 과연 얼만큼 새로운 표준 기능을 구현해 줄지가 기대됩니다. 개인적으로 꽤 많은 부분이 구현되리라 생각하고 혹 빠진 부분은 예전의 tr1처럼 서비스 팩에서 구현되지 않을까 생각합니다.

C++ 새로운 표준이 정해졌으니 남보다 앞서기를 바라는 C++ 프로그래머들은 새로운 C++ 표준을 공부해 봅시다. ^^

근래에 바빠서 글을 거의 올리지 못했는데 다음 글은 새로운 C++ 표준의 바뀐 부분을 간단하게 설명하는 글을 올릴 예정입니다.

그리고 새로 추가되는 표준 라이브러리는 boost 라이브러리에서 많이 들어왔습니다. 그래서 지금이라도 boost 라이브러리를 다운로드 받으면 새로운 표준에 들어갈 라이브러리를 미리 사용할 수 있습니다.

참고

C++0x 사양

위키피디아

http://en.wikipedia.org/wiki/C%2B%2B0x

GCC의 feature 테이블

http://gcc.gnu.org/projects/cxx0x.html

boost 라이브러리

설치 버전 다운로드

http://www.boostpro.com/download/

공식 홈페이지

http://www.boost.org

Direct2D 리소스( Resource ) 기본 개념

Direct2D 에서 리소스라는 것은 단지 메모리를 의미합니다.

그 메모리는 지오메트리(Geometry)나 비트맵 이미지가 될 수도 있습니다.

즉, 이들 리소스는 메모리들이 추상화 된 일종의 개념적인 분류들입니다.

이들 리소스를 처리해서 모니터에 최종적으로 보여주는 것이 Direct2D의 역할입니다.

이전 까지 사용되던 GDI 도 바로 이런 역할을 하는 것입니다.

하지만, GDI와 Direct2D 는 리소스 처리 방식이 완전히 다릅니다.

앞선 시간을 통해서, GDI는 CPU만을 활용한다고 꾸준히 언급했습니다.

반면에, Direct2D는 CPU와 GPU를 동시에 활용합니다.

CPU와 GPU를 동시에 활용하기 때문에,

리소스들도 이들에 맞게 추상적으로 재분류 되어야 합니다.

Direct2D는 이 리소스들을 크게 두 가지 형태로 분류합니다.

바로 디바이스 독립적인 리소스( device-independent resource )와

디바이스 의존적인 리소스( device-dependent resource )로 분류하고 있습니다.

이들 두 리소스들은 모두 ID2D1Resource 인터페이스를 상속받습니다.

디바이스 독립적인 리소스

디바이스 독립적인 리소스라고 하는 것은 CPU에 의해서 처리되는 리소스를 의미합니다.

단어 자체에서 볼 수 있듯이,

이들 리소스는 사용자의 그래픽 하드웨어와 상관없는 처리 결과를 보장합니다.

뒤에서 살펴보겠지만, 지오메트리를 표현하는 인터페이스들이 여기에 속합니다.

( 조금 더 정확히 나열하면, ID2D1DrawingStateBlock, ID2D1Factory, ID2D1Geometry,

ID2D1GeometrySink, ID2D1SimplifiedGeometrySink, ID2D1StrokeStyle 등이 여기에 속합니다. )

아래는 이런 디바이스 독립적인 리소스들의 계층구조를 보여주는 그림입니다.

디바이스 의존적인 리소스

반면에 디바이스 의존적인 리소스는 GPU에 의해서 처리되는 리소스를 의미합니다.

사용자들이 가지고 있는 그래픽 하드웨어들은 매우 다양하기 때문에, 그 기능들을 모두 동일한 방식으로 처리하는 것이 쉽지 않습니다.

( 각각의 하드웨어마다 성능이나 명령어들이 모두 차이가 나기 때문이겠죠..^^ )

즉, 이들은 사용자의 하드웨어들에 따라서 결과가 차이가 날 수 있습니다.

이 차이라는 것은 눈으로 확인 가능한 차이를 얘기하는 것이 아니라,

그래픽 하드웨어들이 생성하는 명령어들과 성능 등과 같은 차이를 얘기하는 것입니다.

우리가 보는 모니터는 그래픽 하드웨어들이 생성한 명령어들의 최종적인 결과입니다.

리소스들도 바로 이 그래픽 하드웨어의 영향을 받아서 결과가 생성되는 것입니다.

앞서 우리가 화면에 렌더링 하기 위해서 만들었던 렌더타겟이나 브러시, 이미지 같은 리소스들은 모두 여기에 속합니다.

아래의 그림은 디바이스에 의존적인 리소스들의 계층구조를 표현하는 그림입니다.

Direct2D는 리소스 처리 방식은 되도록이면 GPU를 활용합니다.

GPU 처리가 불가능하다면, 자동적으로 CPU로 처리하게 됩니다.

GPU를 활용하는 리소스라면, 더욱 높은 품질로 빠르게 처리할 수 있습니다.

이들 리소스에 대한 설명은 다음 시간부터 차근히 살펴보겠습니다.^^

C++ AMP라는 것을 들어보셨나요?근래에 나온 단어입니다.

AMP는 AcceleratedMassive Parallelism의 약자로 병렬 프로그래밍과 관련된 것입니다.

C++ AMP는 2주 전의 AMD의 Fusion 컨퍼런스에서Microsoft의 Herb Sutter씨가(MS의프로그램 언어 아키텍터 이자 C++ 표준 위원 멤버) 처음으로공개한 것으로 다음 버전의 Visual Studio(현재는Visual C++만)에서 GPGPU 프로그래밍환경을 제공하는 것을 뜻합니다.

병렬 프로그래밍에서 대해서 조금 깊게 공부하신 분들은 아마 GPGPU라는것을 들어본 적이 있으리라 생각합니다. GPGPU는 간단하게 말하자면 GPU를 CPU 처럼 사용하자라는 것으로 GPU의 높은 성능을 사용하여 CPU와 똑 같게는 사용할 수는 없지만연산 처리에서 높은 병렬 기능을 사용하여 CPU보다 훨씬 뛰어난 결과를 얻을 수 있습니다.

현재까지 GPGPU 개발환경은NVIDIA의 Cuda와 오픈 아키텍처인 OpenCL,DirectX 베이스의 DirectCompute가 있습니다.

GPGPU 프로그래밍의 단점은 프로그래밍이 복잡하고 아직 레퍼런스가적다는 단점이 있어서 아직은 일반적인 프로그래밍 영역에 들어오지 못하고 있습니다(사실 아직 일반 병렬프로그래밍도 쉽게 사용하지 못하고 있으니..). 그래서 GPGPU가나온 것은 몇 년이 지났지만 아직 일부 전문 영역에서만 사용되고 있었습니다.

그러나 CPU 아키텍처가 멀티코어에서 헤테로지니어스 아키텍처(이기종의 CPU가 결합.CPU+GPU등)로 서서히 넘어가고 있어서 자연스럽게GPGPU 프로그래밍이 부각되고 있었습니다. 하지만 아직도 개발환경의 뒷받침이 부족한 상태였는데드디어 우리 개발자에게 친숙한 Visual C++에서 이런 문제를 해결하려고 합니다.

C++ AMP는 쉽게 말하면Visual C++에서 GPGPU 프로그래밍을 지원하는 것을 말합니다. Visual C++의 뛰어난 개발환경을 토대로 하여 이때까지 복잡했던GPGPU 프로그래밍을 일반 프로그래밍 하듯이 사용할 수 있게 해줍니다. 이로써 GPGPU가 일반 프로그래밍 영역으로 들어 올 수 있는 큰 계기가 되었다고 생각합니다.

C++ AMP에 대해서 AMD의 Fusion 컨퍼런스에서 데모를 시연한 Daniel Moth의 블로그에올라온 글을 정리하면

개발자의 생산성과 이식성을 저해하지 않고 헤테로지니어스 하드웨어 프로그래밍의 허들을 낮게 하여 프로그래밍 일반영역에서 사용할 수 있도록 한다.

현재의 대 규모 병렬 하드웨어(CPU와 GPU)의 사용을 돕기 위한 것만이 아닌 코드의 투자를 미래에 대비한 디자인으로 하여 견고하도록 한다.

Visual Studio의 일부분으로 또 다른 컴파일러나 다른 구문을배울 필요가 없다.

현재의 C++ 언어를 사용하며 C나다른 파생 언어가 아니다.

Visual Studio vNext와 완벽하게 통합하여 지원한다. 편집, 빌드, 디버그, 프로파일러 등 Visual Studio의 다른 모든 기능이 C++ AMP와 같이 동작한다.

기존의 Concurrency Runtime의 일부로 STL와 비슷한 형태의 라이브러리를 제공하여 amp.h 헤더 파일을제공한다.

병렬화를 주 특징으로 하여 헤테로지니어스 하드웨어 위에서 거대한 다 차원 데이터를 아주 쉽게 동작한다.

유일의 코어 C++ 언어 확장을 도입한다.

DirectX(DirectCompute) 위에 구축하지만 C++ AMP에서는 DirectX의 모습은 나타나지 않는다(즉 DirectX를 몰라도 상관 없다).

또 동 세미나에서 기조 연설을 한 Herb Sutter씨의 강연 중 C++ AMP에 관한 내용으로는

C++ AMP에 의해서 기존의C++에서 큰 변경을 가하지 않으면서 언어를 확장하는 점을 강조하여 새로운 언어가 만들어서 개발자에게 혼란을 주는 것을 피했다라는것을 알림.

언어 확장으로 restrict() 함수와 array_view라는 2개의 type이 Key로 잡음. restrict()는 프로세서 아키텍처에 따라서 실행가능한 기능에 제한을 거는 것이고 array_view는 불 균인한 메모리 공간으로의 접근으로 생기는문제를 회피하기 위한 것으로 메모리 공간을 N 차원의 배열로서 작업하는 것을 뜻한다. 메모리 공간의 추상화라고 할 수도 있다. restrict()와 array_view는 프로세서 아키텍쳐와 메모리 공간의 차이를 흡수할 수 있는 것으로 C++ AMP의 중요한 Key이다.

C++ AMP의 컴파일러는Visual Studio의 차기 버전에서 들어갈 예정으로 릴리스는 이번 연말로 예상하고 있다. 또이 컴파일러는 오픈 사양일 예정으로 Windows 상의 VisualStudio 뿐만이 아닌 그 이외의 개발 환경(C++ Builder이나 이클립스 등)에서도 이용할 수 있도록 AMD와 협력 하여 개발 중이라고 한다.

DirectX의DirectCompute를 사용한다고 하니 C++ AMP를 사용한 프로그램은 Windows Vista 이상에서만 사용할 수 있을 것 같습니다(이유는 DirectCompute가 DirectX 10에서 지원하기 때문).

GPGPU에 관심은 있었지만 아직 시기상조라고 생각하는 분들은 C++ AMP가 나오면 개발 허들이 크게 내려가므로 본격적으로 준비를 해도 좋을 것 같습니다. AMD에서는 헤테로지니어스 컴퓨팅 프로그래밍의 전망을 CUDA 등의독자 사양에서 OpenCL이나 DirectCompute 등의오픈 사양으로 이동하고, 전문 프로그래머만 프로그래밍 하는 시대를2011년까지로 보고 그 이후로는 일반 프로그래머가 완전하게 C++로 프로그래밍하는 헤테로지니어스컴퓨팅 프로그램이 올 것으로 보고 있다고 합니다.

저도 이제 슬슬 GPGPU 프로그래밍 쪽으로 들어가볼 예정인데 일단조만간 OpenCL부터 시작해 볼까 합니다. 연말에 VS의 vNext가 나올 수도 있다고 하니 그때 꼭 C++ AMP를 공부해서 그 내용을 공유하도록 하겠습니다^^

참고

헤테로지니어스 멀티 코어 http://jacking.tistory.com/513

Daniel Moth씨의 블로그 http://www.danielmoth.com/Blog/

  위 글을 정리한 한블로그(일본어)
 http://blogs.msdn.com/b/hiroyuk/archive/2011/06/20/10176783.aspx

AMD Fusion 컨퍼런스에서의 데모

비디오 http://channel9.msdn.com/posts/Daniel-Moth-Blazing-fast-code-using-GPUs-and-more-with-C-AMP

슬라이드 http://ecn.channel9.msdn.com/content/DanielMoth_CppAMP_Intro.pdf

일본의 임프레스 사이트에 올라온 Herb Sutter씨의 기존 강연정리 글

http://pc.watch.impress.co.jp/docs/news/event/20110617_453939.html

STL의 컨테이너를 사용해보았다면 forward_list라고 해서 딱히 어려운 부분은 없습니다. 다만 forward_list이 단 방향 리스트라는 것과 다른 컨테이너에서는 지원하는 기능이 일부 없다는 것을 잘 숙지해야 합니다.

필요한 헤더 파일

forward_list는 이름과 같은 ‘forward_list’라는 헤더 파일을 포함해야 합니다.

#include <forward_list>

[예제] forward_list를 사용하여 요소 추가, 순회, 삭제하기

< 결과 >

위 예제를 보면 아시겠지만 forward_list는 std::list에 비해 성능 면의 이점을 가지고 있지만 사용 측면에서는 조금 불편한 점이 좀 있습니다. 그러나 C와 비슷한 성능을 내고 싶은 경우에는 좋은 선택 기가 될 수도 있습니다.

참고

http://msdn.microsoft.com/ko-kr/library/ee373568.aspx

앞에까지는 STL의 알고리즘에 추가된 것들을 다루었는데 이번에는 컨테이너 하나를 소개하겠습니다. 사실 이 컨테이너는 저도 얼마 전까지만 하더라도 새로 추가 된지 몰랐습니다.^^;

새로 추가된 컨테이너의 이름은 ‘forward_list’입니다.

이름을 들어보니 대충 어떤 컨테이너인지 감이 오시죠?^^ 네 이 컨테이너는 기존의 list 컨테이너와 비슷한 종류의 컨테이너입니다.

forward_list를 만든 이유

표준 라이브러리(STL)에는 이미 리스트(std::list) 라이브러리가 있습니다. 이것은 쌍 방향 리스트입니다. list는 사용하기는 편하지만 사용 메모리나 처리 속도에 조금 아쉬운 점이 있습니다. 또 대 부분의 상황에서 쌍 방향 리스트가 필요한 경우보다는 단 방향 리스트만으로 충분한 경우가 자주 있습니다. 이런 이유로 C++0x에서는 단 방향 리스트를 추가하기로 했습니다.

forward_list의 설계 방침

1. 특별한 이유가 없다면 forward_list는 기존의 list의 설계에 맞춘다.

2. 설계 상의 선택 기가 여러 개인 경우 성능(속도와 사이즈)을 최우선 한다(C의 구조체로 구현하는 경우와 비교하여 Zero Overhead로 한다).

3. std::list의 insert와 erase를 forward_list에서도 제공할 수 있지만 구현이 복잡해지고 성능 측면에서 좋지 않으므로 제공하지 않는다.

4. 다른 STL의 컨테이너들에 있는 size 함수를 제공하지 않는다. 이유는 요소 수를 보존하는 멤버를가지고 있으면 C언어에서 구현한 것과 비교해서 불필요한 메모리를 사용한다. 만약 이런 멤버를 가지고 있지 않으면서 size 함수를 지원하면 호출할 때마다 모든 요소를 세어야 하므로 계산량이 O(N)이 된다(그런데 유저는 다른 컨테이너와 같이 size의 계산량이 작을 것이라고 생각할 수 있다). 또 이미 unordered와 같은 연상 컨테이너도 기존의 요소를 만족하지 않고 있다.

STL의 list 컨테이너와 다른 점

forward_list는 기존의 list와 아래와 같은 점이 다릅니다.

1. forward_list는 단 방향 리스트(singly-linked-list)이다. 각 요소는 그 다음 요소를 가리키는 포인터를 하나만 가지고 있다(list은 양 방향 리스트).

2. (단 방향 리스트이므로) list에 비해서 메모리를 작게 사용한다. 이것은 각 요소의 메모리만이 아닌 컨테이너 그 자체의 사이즈도 작다. int 형에 대해서 list는 12바이트라면 forward_list는 8바이트이다(64비트에서는 각각 24, 16).

3. list에 비해 삽입/삭제 속도가 더 빠르지만 그 차이는 크지는 않다

4. 한 방향으로만 이동할 수 있다.

5. 삽입과 삭제는 지정한 요소의 다음 요소만 가능하다.

forward_list의 멤버 리스트

C++03까지의 STL에는 데이터셋에서 가장 작은 요소를 찾을 때는 min_element, 가장 큰 요소를 찾을 때는 max_element를 사용하였습니다.

그런데 만약 최소와 최대를 동시에 찾을 때는 어쩔 수 없이 min_element와 max_element를 각각 호출해야 하는 불필요한 불편한 점이 있었습니다.

C++0x에서는 이런 불편함을 개선하기 위해 한번에 최소와 최고를 찾아주는 minmax_element 알고리즘이 새로 생겼습니다.

minmax_element

minmax_element 알고리즘에는 조건자를 사용하는 버전과 조건자를 사용하지 않은 버전 두 가지가 있습니다. 데이터셋의 자료형이 유저 정의형(class나 struct를 사용한)이라면 조건자가 있는 버전을 사용합니다.

< 예제 코드 >

< 결과 >

미국에서 개최된 TechEd 2011의 강연 중에서 VC++과 관련이 있는 ‘ALM for C++ in Microsoft Visual Studio 2010’ 이라는 세션을 소개하려고 합니다.

이 세션의 내용은 Visual Studio 2010(이하 VS)에서 C++에서 사용할 있는 ALM 기능을 소개하고, VS의 차기 버전(이하 vNext)에 구현될 ALM 기능을 소개하고 있습니다.

사실 저는 이 세션에 대해서 별로 기대하지 않았습니다. 그러나 세션 내용을 보니 저의 생각을 완전히 뛰어 넘었습니다. VS의 차기 버전을 많이 기대하게 되었습니다.^^
이 세션의 내용 중 vNext에 관련된 내용을 정리해 보았습니다.

이 세션의 내용을 짧게 정리하면 ‘기존 VS에서 닷넷만 되고 C++은 안 되는 기능을 이제는 C++에도 동등하게 지원한다’ 입니다.

저는 Visual Studio.NET 2002에서부터 VS에 대한 불만 중 하나가 닷넷 프로그래머나 C++ 프로그래머나 똑 같은 돈을 주고 VS를 구입하는데 왜 tool의 많은 기능 중 닷넷만 되고 C++은 안 되냐라는 것이었는데 이제 이런 불만이 사라질 것 같습니다.

그럼 ‘ALM for C++ in Microsoft Visual Studio 2010’ 세션을 간단하게 소개하겠습니다.

( 본문에 사용한 그림은 VC++ 팀 블로그에 올라온 그림을 사용하였습니다 )

현재 C++에서 VS의 ALM을 모두 사용하고 있는 사람은 3할정도

Visual Studio 2010에서의 ALM 기능

Premium 버전

- ALM과 관련된 기능으로 Code Coverage, Static Analysis, Profiling, Concurrency Profiling을 지원.

Ultimate 버전

- Load Testing, Lab Menagement 지원

- TFS에서는 Version Control, Team Build 지원

vNext에서의 변화

2010에서 지원하던 Architecture tools의 기능을 강화하면서 새로운 기능을 추가

Native의 ALM에 투자를 하여 기존의 많은 ALM 기능을 Native에 대응해 나갈 것임

코드 분석

Architecture Tools  (VS2010에서 지원)

Native 애플리케이션의 아키텍처를 동적으로 시각화하여 의존 관계를 빠르게 파악할 수 있음

이름 공간, 타입, 함수 단위로 자유자재로 의존 관계를 시각화

헤더 파일의 의존 관계도 그래프화(이 기능 사용하면 빌드 시간 단축을 위해 헤더 파일 정리할 때 정말 좋을 것 같습니다).
헤더 파일에 색을 붙여서 구분이 쉬워짐. 또 이미지 파일로 저장도 가능

기존 VS 프로젝트를 드래그&드랍으로 레이어 그림으로 변환. 아키텍처 검증과 의존 관계 생성도 할 수 있음.

그리고 드디어 vNext ALM for C++의 끝판왕 소개입니다.

.......

...........

..............

무려 C++ Unit Test Framework 지원(뭐 사실 2010에서 닷넷은 이미 지원하고 있죠^^;;).

저는 이 기능은 정말 의외였습니다. 제가 tool에서 가장 지원해주기 바라는 기능이 드디어 들어오네요. 이 세션에서도 이 C++ Unit Test Framework 소개할 때 청중들의 박수갈채가 뿜어져 나왔다고 합니다. 아마 저도 이 세션을 들었으면 기립박수를 했을 것 같네요^^

이제 우리 C++ 프로그래머들도 이제 순정(?) Unit Test Framework을 사용할 수 있어 따로 설치하지 않아도 되고 녹색 버튼과 빨간 버튼을 볼 수 있습니다.

단위 테스트 프로젝트 템플릿이 있고, CppUnitTest.h, TEST_CLASS, TEST_METHOD 매크로가 있다고 합니다.

위 그림의 왼쪽이 Unit Test Explorer인데 테스트에 속성을 붙일 수 있는데 이 속성은 TEST_OWNER(), TEST_PRIORITY(), TEST_IGNORE() 등이 있습니다.

Code Coverage

Unit Test Explorer에서 아이콘 클릭으로 코드 커버리지 데이터 리포트를 볼 수 있습니다.

바이너리 단위, 함수 단위로도 가능합니다. 원래 이 기능은 2010에는 있었지만 닷넷만 가능했죠. 이제 이것을 C++에서도 사용할 수 있습니다.

소스 코드의 하이라이트로 커버리지 상황을 시각화 할 수도 있습니다.

앞서 이야기 했듯이 기존에 닷넷만 지원하는 기능을 앞으로는 C++도 사용할 수 있습니다. 그리고 당연하게 vNext에서 새로 만들어지는 기능도 이젠 차별 없이 C++도 지원한다고 합니다.

vNext에서는 VS의 tool 기능을 반쪽만 아닌 닷넷과 같이 모두 사용할 수 있을 것 같아서 너무 좋네요^^

기억을 더듬어 보면 2008이 나오기 전 2007년 겨울에 MS 본사의 VC++ PM이 왔어 앞으로 VC++의 기능이 혁신적으로 개선 될 것이라고 했을 때 일종의 립 서비스라고 생각했고, 2008이 나왔을 때 역시나(물론 이전보다는 좀 좋아졌지만) 라고 생각했습니다. 그러나 2010이 나오면서 인텔리센스를 새로 만든 것을 보고 립 서비스가 아니었구나 라고 생각하게 되었고 이번 세션을 통해서 MS의 VC++에 대한 확고한 의지를 볼 수 있었습니다.

vNext가 정확하게 언제 나올지는 모르겠지만 VC++은 C++0x 기능과 C++ for ALM 기능으로 기대가 정말 많이 되고 나오면 공부할 것이 많을 것 같습니다.

‘ALM for C++ in Microsoft Visual Studio 2010’ 세션에 대한 정보는 VC++ 팀 블로그의 글이나 Channel 9에서 영상으로 볼 수 있습니다.

데이터셋을 시퀸스(연속적인)한 값으로 채우고 싶을 때는 iota 알고리즘을 사용합니다.

앞서 소개한 알고리즘들은 <algorithm> 헤더 파일에 정의 되어 있는 것에 반해 iota 알고리즘은 <numeric> 헤더 파일에 정의 되어 있습니다.

itoa

아래는 예제 코드와 결과 입니다.

< 결과 >

위 예제를 보면 아시겠지만 iota의 세 번째 인자의 값이 시작 값이고, 이후에 값이 하나씩 증가합니다.

is_heap과 is_heap_until는 앞서 소개했던 is_sorted, is_sorted_until과 비슷한 알고리즘입니다. 차이가 있다면 is_heap과 is_heap_until는 정렬이 아닌 Heap을 다룬다는 것만 다릅니다.

is_heap은 데이터셋이 Heap으로 되어 있는지 아닌지, is_heap_until는 데이터셋에서 Heap이 아닌 요소의 첫 번째 위치를 반환합니다.

is_heap

is_heap_until

is_heap과 is_heap_until는 각각 조건자를 사용하는 버전과 사용하지 않는 버전 두 개가 있습니다. 조건자를 사용하지 않는 경우는 operator< 를 사용합니다.

그럼 is_heap과 is_heap_until을 사용한 아주 간단한 예제 코드를 봐 주세요^^

< 결과 >

 

 

 

ps : 자료구조 Heap에 대해서 잘 모르시는 분들은 아래의 글을 참고해 주세요

http://blog.naver.com/ctpoyou/105423523

is_sorted는 데이터셋이(컨테이너나 배열) 정렬되어 있다면 true를 반환하고, 그렇지 않다면 false를 반환 합니다.

is_sorted_until는 데이터셋에서 정렬되어 있지 않는 요소의 첫 번째 위치를 반환합니다.

is_sorted와 is_sorted_until의 원형은 아래와 같습니다.

is_sorted

is_sorted_until

위의 is_sorted와 is_sorted_until의 원형을 보시면 알겠지만 조건자(함수객체)를 사용하는 버전과 사용하지 않는 버전 두 가지가 있습니다.

조건자를 사용하지 않는 경우 기본으로 operator<가 적용됩니다.

프로그래머는 코드로 이해하죠? ^^ 그럼 바로 예제 코드 들어갑니다.

이번 예제는 간단하게 만들기 위해 정수 배열을 사용해 보았습니다. 아마 STL을 이제 막 공부하고 있는 분들은 알고리즘을 STL의 컨테이너에만 사용할 수 있는 것으로 알고 있는 분들도 있을텐데 그렇지 않습니다. 아래 예제는 int 형 배열을 사용하였습니다.

< 예제 코드 >

< 결과 >

제가 http://vsts2010.tistory.com/category/C++/CLI 에 올린 글을 정리한 것으로 보기 편하도록 정리하여 pdf 파일로 만들었습니다.

이후 관련 글을 포스팅 하면 일정 시간이 지난 후 다시 이 글에도 추가하여 배포할 예정입니다.

Native Cpp 개발자를 위한 Cpp-CLI.pdf

이번에 설명할 is_partitioned, partition_point는 그 이름처럼 앞서 소개한 partition_copy와 관계가 있는 알고리즘 입니다.

is_partitioned의 원형

partition_point의 원형

is_partitioned는 데이터셋의 요소가 전반 부와 후반 부 두 개로 나누어져 있는지 조사할 때 사용하고, partition_point는 두 개로 나누어져 있는 데이터셋에서 후반 부의 첫 번째 요소를 가리키는 반복자를 반환합니다.

약간 설명이 애매하죠?^^;

예를 들어 설명하면 온라인 FPS 게임에서 8명이 각각 4명씩 레드 팀과 블루 팀으로 나누어서 게임을 하는 경우 vector로 된 StagePlayers(온라인 게임에서 방에 들어온 유저들을 저장)에 앞 부분에는 레드 팀 플레이어 4명을 차례로 저장하고, 그 이후에 블루 팀 플레이어를 저장하고 있는지 조사하고 싶을 때 is_partitioned 알고리즘을 사용하면 알 수 있습니다(맞다면 true를 반환합니다). 그리고 StagePlayers에서 블루 팀의 첫 번째 플레이어에 접근하고 싶다면 partition_point를 사용합니다.  

나름 쉽게 설명한다고 했는데 이해 가시나요? 만약 이해가 안 간다면 예제 코드를 봐 주세요^^

< 예제 >

< 결과 >

예제 코드를 보니 쉽게 이해 되시죠? 그럼 저는 아는 걸로 생각하고 다음 포스팀에서는 다른 알고리즘을 설명하겠습니다^^

 

첫 번째 Direct2D 프로그래밍~  

지난 시간을 통해서 Direct2D의 필요성에 대해서, 제가 열심히(?) 언급해 드렸습니다.^^

이번 시간에는 Direct2D 프로그래밍의 세계에 대해서 들어가기 전에,

간단하게 프로그램을 작성해 볼 것입니다.

부끄럽지만, 저는 박식한 이론 내용 없이도 많은 프로그래밍 작업을 했었습니다.^^

그 만큼, 직접 프로그램을 작성하면 쉽게 이해할 수 있는 부분이 많이 있을 것입니다.

기본적으로 Direct2D는 2차원 그래픽을 만들기 위한 API입니다.

기존의 GDI를 이용한 프로그램의 일부분을 Direct2D로 대체를 하는 것만으로도 성능을 향상시킬 수 있습니다.

기본적으로 Direct2D로 작업하는 순서는 다음과 같습니다.

1. Direct2D 팩토리를 생성한다.
2. 팩토리에서 렌더타겟을 생성한다.
3. 렌더타겟에서 리소스들을 생성한다.
4. 생성 되어진 리소스들을 이용해서 그리기 작업을 수행한다.

Direct2D의 모든 작업은 위의 순서를 따릅니다.

이제 이들 순서를 어떻게 API로 표현하는지 살펴보겠습니다.

화면 작업을 위해 준비하기

첫 번째로 작성해볼 프로그램은 특정 색상으로 화면을 채우는 작업을 하는 것입니다.

먼저 마법사로 프로젝트를 생성하고, "stdafx.h" 헤더파일에 Direct2D와 관련된 선언을 추가시켜주기 바랍니다.

위의 내용은 Direct2D와 관련된 라이브러리와 헤더파일을 선언해 준 것입니다.

그리고 작업을 수행할 .cpp 파일에 전역 변수를 두 개 선언합니다.

Direct2D 프로그래밍을 위해서 가장 먼저 해야 하는 일은 ID2D1Factory 를 생성하는 일입니다.

D2D1CreateFactory()의 첫 번째 인자는 멀티 스레드 지원 여부를 설정합니다.

이번 내용에서는 싱글 스레드만을 사용합니다.( 멀티스레드 어려워요~~)

두 번째 인자는 팩토리가 생성되어서 결과를 반환 받을 수 있는 팩토리 포인터를 넘겨줍니다.

이것이 성공하면, Direct2D 와 관련된 작업을 할 수 있게 됩니다.( 참~~ 쉽죠잉!! )

우리가 만들려고 하는 프로그램이 화면에 어떤 내용을 그리는 것입니다.

화면에 무엇인가를 그린다는 개념은 하드웨어 입장에서 봤을 때는 메모리에 값을 쓰는 것입니다.

여러분들이 보고 있는 모니터 화면은 거대한 메모리에 색상 값이 기록되어 있는 것입니다.

이번에 할 일은 바로 이 메모리 영역을 생성하는 일입니다.

Direct2D의 가장 큰 장점이 바로 이 메모리 영역에 값을 기록하는 작업( 이하 렌더링 )이

GDI를 이용하는 것보다 훨씬 빠르다는 것입니다.

왜냐하면, 바로 이 메모리 영역이 그래픽 카드에 있기 때문입니다.

그리기 명령을 수행할 메모리 영역을 생성하기 위해서 다음과 같이 코딩을 합니다.

바로 이 메모리 영역을 렌더타겟( RenderTarget ) 이라 합니다.

CreateHwndRenderTarget() 의 첫번째 인자는 화면에 대한 정보를 설정합니다.

픽셀 포맷이나 DPI 등의 많은 플래그와 옵션이 있지만, 현재는 디폴트 정보로 넘겨주었습니다.

두 번째 인자는 하드웨어 가속을 받는 렌더링에 대한 옵션을 설정합니다.

간단하게 크기 정보만 넘겨주는 것으로 마무리했습니다.

마지막으로는 이 API 호출이 성공했을 때 리턴되어지는 렌더타겟의 포인터를 저장할 변수를 넣어주었습니다.

이렇게 함으로써 간단하게 우리는 하드웨어 가속을 받을 수 있는 렌더타겟을 생성할 수 있습니다.

옵션이나 인자에 대한 설명을 충분히 드리면 좋겠지만, 너무 많습니다.^^

중요한 인자나 옵션에 대해서만 설명 드리는 점 양해 부탁 드립니다.

이제 우리는 렌더타겟을 가지고 있으니 이 메모리 영역에 값을 쓰면, 모니터로 결과를 확인할 수 있습니다.

윈도우가 화면에 그리기 위해서 발생하는 메시지가 WM_PAINT 입니다.

저는 이 메시지를 처리해서, 원하는 색상으로 렌더타겟의 색상을 채울 것입니다.

다음과 같이 코딩을 합니다.

이번 코드를 실행시키면, 파란색으로 칠해진 윈도우 프로그램을 만나게 될 것입니다.

더 정확하게 얘기하면, 메모리 영역( 렌더타겟 )이 파란색 색상데이터로 채워진 것입니다.

샘플을 올려둡니다.( SimpleDraw.zip )

도움이 되셨으면 좋겠습니다.^^

 


GDI vs Direct2D 비교해 보기.  

제가 아무리 Direct2D가 GDI보다 좋다고 혼자 말하는 것 보다, 여러분들이 직접 결과를 확인하는 것이 좋습니다.

그래서 이번에는 GDI와 Direct2D를 이용해서 타원을 렌더링 할 것입니다.

그리고 결과로 나오는 것을 보고, 여러분들이 직접 확인해 보기 바랍니다.

GDI 로 작업하기.

GDI를 이용하는 것은 전통적인 윈도우 프로그래밍에서 사용되던 방식입니다.

주변에서 이와 관련한 많은 내용들을 접할 수 있어서, 내용에 대한 자세한 설명은 생략하겠습니다.

Windows 운영체제에서 모든 드로잉(Drawing) 작업은

디바이스 컨텍스트 오브젝트( device-context object )를 통해서 실행이 됩니다.

이를 줄여서 'DC' 라고 줄여서 얘기합니다.( 다 아시죠? ^^ )

DC란, 윈도우즈 운영체제에서 컴퓨터 모니터나 프린터에 그리기 명령을 수행하기 위한

여러 속성 정보들을 구조화한 데이터입니다.

우리는 Windows API를 이용해서 DC를 이용한 그리기 작업을 수행할 수 있습니다.

DC를 이용하면, 우리는 어떠한 하드웨어 장치와는 관련이 없이 공통된 형식으로 화면에 그릴 수 있습니다.

이것이 가능한 이유는 DC는 CPU가 그리기 작업을 처리해 주기 때문입니다.

<코드>

HDC hDC;

HBRUSH hBrush,

hOldBrush;

if (!(hDC = GetDC (hwnd)))

return;

hBrush = CreateSolidBrush (RGB(0, 255, 255));

hOldBrush = SelectObject (hDC, hBrush);

Rectangle (hDC, 0, 0, 100, 200);

SelectObject (hDC, hOldBrush);

DeleteObject (hBrush);

ReleaseDC (hwnd, hDC);

</코드>

위의 코드는 간단히 DC를 이용해서 사각형을 그리는 코드입니다.

위에서 보는 것과 같이,

GetDC() 라는 API 를 통해서 현재 윈도우 애플리케이션에 대한 DC를 얻어서 작업을 수행합니다.

DC와 관련된 코드를 살펴보면, SelectXXX() 형식을 자주 볼 수 있습니다.

이는 DC가 일종의 상태 정보를 유지하고 있기 때문입니다.

예를 들면, 빨간 펜과 파란 펜으로 두 개 동시에 작업을 할 수는 없습니다.

하나의 펜으로 먼저 작업을 한 후에, 작업한 펜을 제거하고 다음 펜을 선택한 후에 작업을 해야 한다는 얘기입니다.

이점을 잘 고려해서 작업을 해야 하는 것이죠.

이것은 DC를 이용하는 하나의 방법일 뿐입니다.

만약 WM_PAINT 메시지 내부에서 처리하고자 한다면, 아래와 같은 구조를 취할 수 있습니다.

<코드>

PAINTSTRUCT ps;

case WM_PAINT :

hdc = BeginPaint(hWnd, &ps);

{

DoSomething()

}

EndPaint(hWnd, &ps);

break;

</코드>

PAINTSTRUCT 는 내부에 DC 관련 멤버 변수를 가지고 있습니다.

BeginPaint()를 통해서 DC 정보가 채워지게 되는 것입니다.

이러한 DC를 활용하는 것이 GDI 를 이용하는 것의 핵심입니다.

이와 관련된 내용을 더 언급하고 싶지만, 이 정도에서 정리하겠습니다.

이미 많은 분들이 저 보다는 훨씬 많은 지식을 가지고 있을 것이며,

관련 자료들도 이미 훌륭히 찾아 볼 수 있기 때문입니다.^^

우리가 지금 하려는 것은 GDI와 Direct2D의 비교입니다.

프로젝트를 만들고, 시스템을 셋팅하시기 바랍니다.( Direct2D 오브젝트도 생성해 주어야 합니다. )

WM_PAINT 메시지에 이 두 가지 방법을 사용해서 렌더링 하는 함수를 호출했습니다.

( 제가 정의한 함수들입니다. )

먼저, Direct2D를 이용해서 타원을 렌더링 하는 코드를 살펴보겠습니다.

이 방법은 뒤에도 설명을 하겠지만, Direct2D에서 DC를 활용하는 렌더링 방법입니다.

몇몇 생소한 개념들이 보이지만, 이들에 대해서는 차후에 설명을 할 것입니다.

GDI를 활용해서 타원을 렌더링 하는 코드는 다음과 같습니다.

자, 이제 이 둘의 결과는 예제 코드를 실행시키면, 다음과 같이 확인할 수 있습니다.

이는 타원의 일부를 캡쳐한 화면입니다.

좌측은 Direct2D의 결과이고, 우측은 GDI를 이용한 결과입니다.

겉으로 보기에는 차이가 없어 보이지만,

자세히 보면 우측의 경우는 울퉁불퉁한 계단 현상이 심한 것을 알 수 있습니다.

( 잘 보이지 않는다면, 샘플을 실행시켜보시기 바랍니다.^^ )

분명히 같은 기능을 하는 두 함수이지만, 결과에서는 이렇게 차이가 납니다.

샘플 파일( BasicRender.zip )을 같이 첨부했으니, 도움이 되셨으면 좋겠습니다.^^

BasicRender.zip

SimpleDraw.zip