CTS( Common Type System ) 와 관련한 내용을 위주로 정리했습니다. MSDN 의 Types section 을 요약하면서 내용을 보충한 것입니다.

CS_Types.pdf

'Programming > .NET' 카테고리의 다른 글

[ 4 ] DataBinding  (0) 2012.10.14
[ 3 ] Dependency property.  (0) 2012.10.11
[ 2 ] XAML  (0) 2012.10.10
[ 1 ] WPF Architecture.  (0) 2012.10.08
[ 6 ] Proerty, indexer, attribute  (0) 2012.10.05
[ 5 ] Delegate and event.  (0) 2012.10.02
[ 4 ] Classes and structs  (0) 2012.09.27
Extension Methods  (0) 2012.09.26
[ 3 ] .NET Garbage Collection.  (0) 2012.09.25
[ 1 ] .NET Framework 4.0 소개.  (0) 2012.09.20

주의 : 오류가 있을 수도 있습니다. 이상하면 참고 자료들을 참조하세요.


Motive.


일반적으로 검기같은 것을 구현하거나 path 를 만들 때 매개변수화된 커브( parameterized curve )를 사용한다. 독자들은 여러 가지 종류의 커브에 대해 들어 보거나 구현한 적이 있을 것이다. 아티스트에게 툴을 사용해서 커브를 구성하라고 할 때 가장 직관적인 형태로 편집할 수 있는 것은 Catmull-Rom spline 이다. Catmull-Rom spline 으로 구글링을 해 보니 어떤 분이 Catmull-Rom spline 에 대해서 잘 정리하셨다. 혹시 Catmull-Rom spline 이 무엇인지 모른다면 다음 링크를 참조하라.


http://blog.naver.com/PostView.nhn?blogId=sorkelf&logNo=40154552485


Catmull-Rom spline 도 그렇고 다른 커브들도 그렇지만 매개변수화된 커브들은 [ 0, 1 ] 의 시간 사이에서 보간되어 최종 위치를 계산하게 된다. 그런데 이 커브들의 동작을 살펴 보면 제어 점의 거리가 멀면 긴 커브를 생성하는데, 제어점을 지나는 시간은 동일하다. 예를 들어 두 개의 구간( segment )을 가진다고 하면 각 구간을 지나가는 시간은 동일하다.


예를 들어 커브를 매개변수 t 에 대해서 매개변수화했고, t 가 1.0 일 때 1초가 지나도록 설정했다고 하자. 그러면 아래 그림과 같이 두 개의 구간으로 이루어진 Catmull-Rom spline 을 지나가는 데는 2초가 걸린다( 물론 아래 그림은 대충 그린 것이기 때문에 실제의 모양과는 차이가 있다 ).

여기에서 두 가지 질문을 던질 수 있다.

  • 0.4 초까지 진행했을 때 얼마의 거리를 이동했을까?
  • 두 구간을 지나가는데 동일한 속도로 이동하게 하려면 어떻게 해야 할까?

이 두 가지 문제를 풀기 위해서 공통적으로 필요한 것이 호의 길이( arc length )를 구하는 것이다.


Arc Length.


커브에서 arc length 라는 것은 곡선을 직선으로 폈을 때의 길이를 의미한다. 즉 커브를 따라 움직였을 때의 거리라고 할 수 있다. 3차원에서의 커브는 vectorized function 이라고 할 수 있으며, 이 커브의 arc length 를 구하기 위한 방법은 아래 링크에 나와 있다.


Arc Length And Curvature.



식을 보면 엄청나게 복잡해 보인다. 위의 식은 다음과 같이 풀어 볼 수 있다.

  • 매개변수화된 커브의 x, y, z 성분을 시간 t 에 대해 미분한다.
  • 각 미분결과를 제곱한 다음에 더하고 그 제곱근을 구한다.
  • a 와 b 구간에서 그 제곱근들을 적분한다.

손발이 마구 오그라드는 것을 느낄 수 있을 것이다.


하지만 개념을 이해하면 매우 단순한 알고리즘이다. 일단 2차원에서 생각하는 것이 편하기 때문에 2차원에서 설명하도록 하겠다. 

아래 그림과 같은 커브가 있다고 하자. 커브의 어떤 구간에서 dx 만큼 이동할 때의 변화량은 dy 이다. 우리가 알고 있는 미분이 바로 아래 그림과 같다.

그런데 문제는 우리가 매개변수화된 커브, 즉 vectorized function 을 가지고 있다는 것이다. 그러면 이 vectorized function 을 미분한다는 의미는 무엇일까? 시간축 개념을 도입해 보도록 하자.


이제 질문에 답을 할 수가 있다. dt 만큼의 시간이 지났을 때 각 성분별로 dx, dy 만큼의 변화량을 가지고 있다고 표현할 수 있다. 이제 이야기가 좀 쉬워진다. 그러면 저 위의 빨간 선의 거리는 어떻게 구하는가?



매우 단순한 2 차원 상에서 거리 구하기 문제이다. 그렇다면 3 차원 상에서도 마찬가지로 확장해 볼 수 있다.



자 이제 "아주 짧은 시간" t 만큼 이동한 거리를 구했으니, [ a, b ] 구간에서 이를 모두 더하면 호의 길이를 구할 수 있다. 이게 바로 적분식으로 표현되어 있다. 이제 다시 식을 살펴 보자. 쉽게 이해가 갈 것이다.



어렵게 생긴 표현식들도 의미를 곰곰히 따져 보면 쉽게 이해할 수 있다. 어떤 시간에 이동한 거리를 구하는 것과 일정한 속도로 이동하는 것은 각 구간의 arc length 를 구한 다음에 적절한 연산을 수행하면 구할 수 있다. 이는 독자의 상상에 맡기도록 하겠다.


식의 마지막에 v(t) 라는 것이 나와 있다. 이는 속도( velocity )를 의미한다. 단위 시간당 각 축에 대한 변화량은 단위 시간당 속도라는 의미와 같다. 즉 우리는 속도를 알고 있을 때 그것을 적분하면 이동 거리를 알 수 있다고 생각할 수 있다.

원문 : Introducing the .NET Framework 4.0

주의 : 번역이 개판이므로 반드시 원문을 참조하십시오.

주의 : 가독성을 높이기 위해 잘 알려진 용어나 발음이 유사한 용어는 한글로 표기합니다.

주의 : 허락받고 번역한 것이 아니므로 언제든 내려갈 수 있습니다.


Introducing the .NET Framework 4.0.


Visual Basic 2010 개발자로서, 당신은 응용프로그램을 향상시킬 수 있는 개념과 기술에 대해 이해할 필요가 있다; Microsoft .NET Framework 가 그것이다. .NET Framework( 혹은 단순하게 .NET 이라 부르기도 함 )는 당신이 생성하려고 하는 차세대 응용프로그램을 만들기 위한 기반을 제공한다. 비록 .NET Framework 의 모든 관점에 대해서 다루는 것은 불가능하지만, 이 장에서 당신은 .NET Framework 구조에 대한 기본, 그것이 단순한 platform 이 아닌 이유, 그리고 Base Class Library 및 도구들에 대한 개념에 들을 배우게 된다. 이 장은 이 책의 나머지 부분에서 전반적으로 사용하게 되는 중요한 개념과 기술에 대해서도 소개한다.


What Is the .NET Framework.


Microsoft .NET Framework 은 복잡한 기술인데, 이는 차세대 응용프로그램들을 빌드하고, 실행하고, 관리하기 위한 기반을 제공한다. 레이어를 가지고 표현해 보면, .NET Framework 는 Microsoft Windows 운영 체제와 당신의 응용프로그램 사이에 위치한 레이어이다. .NET 은 platform 이지만, 기술( technology )로서 정의되어 있기도 하다. 왜냐하면 그것은 운영체제와 관련이 있는  라이브러리, 실행 도구, 관계 및 통합과 같은 부분들을 포함하고 있기 때문이다. Microsoft Visual Studio 2010 은 새로운 버전의 .NET Framework 4.0 에 의존한다. Visual Basic 2010, C# 4.0, F# 2010 과 같은 것들은 .NET Framework 에 의존하는 .NET 언어이며, 이들은 .NET Framework 4.0 을 위한 응용프로그램을 빌드할 수 있다. 이 새로운 버전의 기술은 몇 가지 중요한 기능을 소개하는데, 그것들에 대해서는 나중에 설명할 것이다. 이 장에서 당신은 .NET Framework 에서 가장 중요한 기능들에 대해 훓어 볼 것이고, 이를 통해 당신은 Visual Basic 2010 을 사용해서 빌드된 응용프로그램이 빌드되고 실행되는 방법에 대해서 알게 될 것이다.


Where Is the .NET Framework.


Microsoft Visual Studio 2010 을 설치할 때, 설치 프로세스는 .NET Framework 4.0 을 설치한다. .NET 은 %windir%\Microsoft\Framework\4.0 이라는 이름의 폴더에 설치된다. 만약 이 폴더를 Windows Explorer 로 열어 본다면, 당신은 하위 폴더들과 라이브러리들, 그리고 실행 도구들을 찾아볼 수 있다. 대부분의 DLL 라이브러리들은 Base Class Library 를 구성한다. 반면에 대부분의 실행 도구들은 서로 다른 종류의 작업들을 Visual Studio 2010 에 의해 실행된다. 하지만 그것들을 커맨드라인에서 실행할 수도 있다. 이 장의 뒷 부분에서 우리는 Base Class Library 에 대해서 설명하고, 그 도구들에 대한 개관을 제공할 것이다; 지금은 Vbc.exe 라는 이름을 가진 파일의 위치만 알고 있으면 된다. 그 파일은 Visual Basic Compiler 이며 커맨드라인 도구이다. 대부분의 경우에 당신은 직접 Visual Basic Compiler 를 실행할 필요가 없다. 왜냐하면 당신은 Visual Basic 응용프로그램들을 Visual Studio 2010 내부에서 작성하여 빌드할 것이며, IDE 가 당신을 위해서 컴파일러를 실행할 것이기 때문이다. 그러나 당신이 Windows 의 노트패드를 사용해 매우 복잡한 응용프로그램을 만들고 나서 Vbc 를 실행할 수 있다는 것을 언급해둘 필요는 있다. 마지막으로 .NET Framework 4.0 은 Microsoft 로부터 무료로 얻을 수 있다는 것도 언급해 둘 필요가 있다. 이는 Visual Basic 컴파일러도 .NET 과 함께 무료로 제공된다는 것이며, 이는 2002 년에 처음 릴리즈되었던 버전으로부터 이어진 .NET 개발을 특별하게 만들어 주는 철학이다.


The .NET Framework Architecture.


.NET Framework 의 구조를 더 잘 이해하기 위해서는, 그것을 레이어로 형태의 구조로 생각하라. 그림 1.1 은 .NET Framework 4.0 의 구조를 고수준에서 표현한 것을 보여 준다.


그림 1.1 .NET Framework 4.0 구조.


첫 번째 level 은 운영체제이다; .NET 레이어는 시스템과 응용프로그램 사이에 위치한다. 두 번째 level 은 Common Language Runtime( CLR )인데, 이는 대부분의 작업을 처리하는 .NET Framework 의 일부이다. 우리는 이 장의 뒷 부분에서 CLR 에 대해서 논의할 것이다. 다음 level 은 Base Class Library( BCL )인데, 이는 응용프로그램을 생성할 때 당신의 코드와 Visual Basic 에 의해서 사용될 수 있는 모든 .NET 오브젝트들을 제공한다. BCL 은 WPF, Windows Forms, ASP.NET, WCF 등과 같은 응용프로그램을 빌드하면서 사용하는 몇 가지 .NET 기술들에 대한 기반을 제공하기도 한다. 마지막 level 은 이전 레이어들에 의존하는 응용프로그램을 의미한다.


이전 버전과의 차이점.

당신이 Visual Basic 2008 에서 Visual Basic 2010 으로 업그레이드했다면, 가장 큰 차이점은 .NET 4.0 이 standalone infrastructure 라는 것을 깨닫게 된다는 것이다. .NET Framework 3.5 는 이전에 설치된 .NET 2.0 과 .NET 3.0 을 필요로 하는 incremental framework 이었다는 것을 기억할 것이다. 예를 들어 LINQ 는 .NET 3.5 의 일부이지만, WPF 는 .NET 3.0 의 일부이며, Windows Forms 는 .NET 2.0 의 일부이다( 그림 1.2 를 보라 ). .NET 4.0 을 사용하면 이러한 incremental structure 가 사라진다. 그리고 모든 framework, BCL, 그리고 도구들이 새로운 버전의 일부가 된다.


그림 1.2. .NET Framework 3.5 SP1 의 incremental architecture.



BCL 에 의해 노출되는 다양한 framework 들이 이 책에서 나중에 논의되지만, 이 장에서는 라이브러리에 대한 개관을 보게 될 것이고, 그것들이 작동하는 방식과, 당신이 그것을 사용하는 방법에 대해서 이해할 수 있을 것이다. 그러나 BCL 을 테스트해 보기 전에, Common Language Runtime 을 살펴 보자.


The Common Language Runtime.


이름이 의미하고 있듯이, Common Language Runtime 은 모든 .NET 언어들에 대한 공통적인 기반( infrastructure )를 제공한다. 이 기반은 응용프로그램의 실행을 제어할 책임이 있고, 메모리 관리나 시스템 리소스에 대한 접근, 보안 서비스 등과 같은 작업들을 관리할 책임이 있다. 이러한 종류의 공통 기반은 서로 다른 Win32 프로그래밍 언어들과의 차이를 메꾸는 가교 역할을 한다. 왜냐하면 모든 .NET 언어들은 같은 기능을 가지기 때문이다. 더우기 Common Language Runtime 은 응용프로그램이 관리되는( managed ) 환경에서 실행될 수 있도록 해 준다. "관리되는"이라는 용어는 .NET 개발에서 기본적인데, 다음 절에서 설명한다.


Writing Managed Code.


Visual Studio 2010 개발에 대해서 이야기할 때, 더욱 일반적으로는 .NET 개발에 대해 이야기할 때, 당신은 managed code 를 작성하는 것에 대해서 자주 들었을 것이다. 첫 번째 버전의 .NET 이전에( 혹은 아직 .NET 개발 환경이 아닐 때 ), 개발자가 시스템 리소스와 운영 체제와 상호작용하기 위한 책임을 가지는 유일한 사람이었다. 예를 들어 운영 체제의 일부에 접근하거나 오브젝트들을 위한 메모리 할당을 관리하는 것을 고려하는 것은 개발자가 고려해야만 하는 작업이었다. 다르게 표현하면, 응용프로글매은 시스템과 직접적으로 상호작용하지만, 당신이 쉽게 이해할 수 있듯이 이러한 접근은 보안 이슈뿐만 아니라 위험할 수도 있는 피해들 때문에 큰 제약을 가지고 있다. 대신에 .NET Framework 은 관뢰되는 환경을 제공한다. 이는 응용프로그램이 운영체제가 아니라 .NET Framework 과 통신한다는 것을 의미하며, .NET 런타임은 응용프로그램의 실행 뿐만아니라, 메모리 관리, 리소스 관리, 시스템 리소스들에 대한 접근까지 관리할 책임이 있다. 예를 들어 Common Language Runtime 은 만약 응용프로그램이 .NET 보안 영역에 따라 완전히 신뢰되는( full-trusted ) 것으로 간주되지 않으면, 그것이 특정 시스템 리소스에 접근하는 것을 방지할 수 있다.


시스템에 연결.

당신은 여전히 운영체제와 직접적으로 상호작용할 수 있다. 예를 들어 Windows API 를 실행하는 것이다( 이는 Platform Invoke 나 P/Invoke 라고 알려져 있기도 하다 ).  이 기술은 엄격히 요구될 때만 사용될 수 있는 비관리 코드를 작성하는 것으로 알려져 있다.이 주제는 49 장의 "Platform Invokes and Interoperability with the COM Architecture" 에서 논의된다.


관리 코드의 작성과 Common Language Runtime 의 존재는 응용프로그램이 컴파일러에 의해 생성되는 방식에도 영향을 미친다.


.NET Assemblies.


Visual Basic 6 나 Visual C++ 과 같은 전통적인 Win32 개발 환경에서, 당신의 소스 코드는 컴파일러에 의해서 분석되는데, 그것은 이진 실행 파일들을 생성한다. 그 파일들은 운영체제에 의해 직접적으로 해석되고 실행될 수 있다. 실제로 Visual Basic 6 와 C++ 에 의해서 빌드된 Win32 응용프로그램은 런타임을 사용하지만, 다른 프로그래밍 언어를 사용해서 개발된 응용프로그램을 가지고 있다면, 적절한 런타임을 설치해야만 한다. .NET 개발에서는 모든 것이 매우 다르다. 당신이 응용프로그램을 개발하는 데 사용하고 있는 .NET 언어가 무엇이든 간에, 컴파일러는 어셈블리( assembly )를 생성한다. 이는 .NET 실행 코드를 포함하고 있으며, 두 종류의 필수 요소로 구성된다 : MSIL 코드와 메타데이터( metadata ). MSIL 은 Microsoft Intermediate Language 이다. 이는 개체지향적이며, ( CPU 의존적인 명령어 집합을 구현하는 실행파일을 빌드하기 보다는 ) CPU 독리적인 명령어 집합을 제공하는 고수준 어셈블리 프로그래밍 언어이다. MSIL 은 서로 다른 .NET 언어로 작성된 같은 프로그래밍 작업들이 같은 IL 코드를 생성한다는 의미의 공통 언어이다. 메타데이터는 코드 내에 구현된 타입들과 관련된 정보 집합이다. 그러한 정보는 서명( signature ), 함수, 프로시저, 타입의 멤버, 외부에서 참조되는 타입의 멤버들을 포함할 수 있다. 기본적으로 메타데이터의 목적은 .NET Framework 에 대한 코드를 기술하는데 있다. 어셈블리가 .exe 확장자를 가질 수 있음에도 불구하고, 앞에서 언급한 구조 때문에 그것은 운영체제에 의해 직접적으로 실행될 수 없다. 사실 당신이 .NET 응용프로그램을 실행할 때 운영체제는 그것을 .NET 어셈블리로 인식하고( 왜냐하면 .NET 과 Windows 사이에는 엄격한 협력이 존재하기 때문이다 ), Just-In-Time 컴파일러를 실행한다.


The execution Process and the Just-In-Time ( JIT ) Compiler.


.NET 컴파일러들은 IL 코드와 메타데이터를 포함하는 어셈블리들을 생성한다. 실행을 위해 어셈블리를 시작( launch )하면, .NET Framework 은 모든 정보를 패키징( package )하며 그것들을 운영체제가 이해하고 실행할 수 있는 실행파일로 번역한다. 이 작업은 Just-In-Time( JIT ) 컴파일러가 책임진다. JIT 는 코드를 실행 전에 실시간에( on-the-fly ) 컴팡리하며, 컴팡리된 코드를 실행할 수 있는 상태로 유지시킨다. 그것은 method level 에서 동작한다. 이는 그 코드가 실행되기 전에 응용프로그램의 진입점( 보통 Sub Main )을 먼저 찾은 다음에, 진입점에 의해서 참조되거나 실행되는 다른 프로시저나 함수들( .NET 용어로는 메서드들 )을 컴파일한다는 것을 의미한다. 만약 외부 어셈블리에 정의된 코드를 가지고 있다면, 그 메서드가 실행되기 전에 JIT 컴파일러가 어셈블리를 메모리에 로드한 다음에 코드를 컴파일한다. 물론 외부 어셈블리를 메모리에 로딩하는 것은 시간이 걸리는 작업이며 성능에 영향을 미치지만, 좀처럼 거의 사용하지 않는 메서드들을 외부 어셈블리에 배치하는 것은 좋은 아이디어일 수 있으며, 비슷한 방식으로 거의 사용하지 않는 코드들을 독립된 메서드들에 배치하는 것도 좋은 아이디어일 수 있다.


The Base Class Library.


.NET Framework 의 Base Class Library( BCL )는 수 천개의 재사용 가능한 타입( type )들을 제공하는데, 당신은 그것들을 당신의 코드에서 사용할 수 있으며, 그것들은 Windows Presentation Foundation, ASP.NET, LINQ 등과 같은 모든 .NET 기술들을 다루고 있다. Base Class Library 에서 정의된 타입들은 비관리 코드와 Windows APIs 를 호출하지 않고, 외부 컴포넌트에 대한 의존없이 수백만개의 일을 할 수 있도록 해 준다. 타입은 오브젝트가 표현해야 하는 것이 무엇인지를 진술하는 것이다. 예를 들어 String 과 Integer 는 타입이다. 그리고 당신은 String 타입의 변수( 즉 텍스트 메시지 )를 가지거나, Integer 타입의 변수( 즉 숫자 )를 가질 수 있다. 타입은 Class 와는 다르다. 사실 타입은 두 종류이다 : 참조형( reference type )과 값형( value type ). 이 주제는 4장의 "Data Types and Expressions"에서 다룬다 - 클래스는 단지 참조형일 뿐이다. BCL 에서 타입들은 네임스페이스( namespace ) 내에 들어가 있는데, 네임스페이스는 타입들의 컨테이너처럼 동작하고, 그것의 이름은 그것들이 가리키고 있는 기술과 엄밀한 관련이 있다. 예를 들어 System.Windows.Forms 네임스페이스는 Windows Forms 응용프로그램을 사용해 작업하기 위한 타입들을 구현하며, System.Web 은 Web 응용프로그램을 사용해 작업하기 위한 타입을 구현하는 식이다. 3장 "The Anatomy of a Visual Basic Project" 와 9장 "Organizing Types Within Namespaces" 에서 더욱 세부적인 네임스페이스에 대한 설명을 찾아볼 수 있다. 기본적으로 System 으로 시작하고 있는 네임스페이스의 이름은 BCL 의 일부이다. Microsoft 라고 시작하는 이름을 가진 일부 네임스페이스들이 있는데, 그것들도 BCL 의 일부이다. 이러한 네임스페이스들은 ( 코드 생성과 같은 ) 특별한 시나리오에서 그것들을 당신의 코드에서 사용할 수 있기는 하지만, 보통의 경우에는 Visual Studio 개발 환경과 Visual Basic 컴파일러에 의해서 사용된다. 


BCL 은 몇 개의 어셈블리로 구성된다. 가장 중요한 것은 MsCorlib.dll( Microsoft Core library )인데, 그것은 .NET Framework 의 일부이며, 당신의 프로젝트에서 항상 요구될 것이다. 다른 어셈블리들은 특정 기술에 따라 자주 사용될 수도 있다; 예를 들어 System.ServiceModel.dll 어셈블리는 BCL 을 Windows Communication Foundation main infrastructure 와 통합한다. 또한 어떤 네임스페이스는 다른 기술을 위한 infrastructure 를 제공하지 않으며, 그것들은 특별한 시나리오에서만 사용된다; 결국 그것들은 MsCorlib( Microsoft Core Library )의 외부 어셈블리에서 정의된다. 이러한 모든 어셈블리들과 네임스페이스들은 적절한 장에서 소개될 것이다.


.NET Language.


Microsoft 는 .NET Framework 4.0 을 위한 몇 개의 프로그래밍 언어를 제공한다. Visual Studio 2010 을 사용해, 당신은 다음과 같은 통합된 프로그래밍 언어들을 사용해 응용프로그램을 개발할 수 있다 :

  • Visual Basic 2010.
  • Visual C# 4.
  • Visual F# 2010.
  • Visual C++ 2010.

Visual J# 은 더이상 .NET Framework 패밀리의 일부가 아니다. 당신의 Phython 과 Ruby 와 같은 동적 언어들에 대한 Microsoft 식의 구현을 사용해 네이티브 언어들을 통합할 수도 있는데, 그것들은 각각 IronPython 과 IronRuby 로 알려져 있다.


IronPython 과 IronRuby 는 어디에 있는가?

IronPython 과 IronRuby 는 현재 Microsoft 에서 개발중이며, CodePlex 커뮤니티의 오픈소스 프로젝트로서 이용가능하다. 당신은 IronPython 을 http://ironpython.codeplex.com 에서 받을 수 있다. 당신은 IronRuby 를 http://ironruby.codeplex.com 에서 찾을 수 있다.


Fortran, Forth, Pascal 과 같은 유명한 프로그래밍 언어의 .NET 을 위한 서드파티( third-party ) 구현들도 있느데, 이것들에 대해 논의하는 것은 이는 이 장이나 이 책의 목적이 아니다. 하지만 이 언어들이 .NET Framework base class library 의 이점 및 VB 나 C# 과 같은 infrastructure 를 취한다는 것을 아는 것은 중요하다. 이는 Common Language Runtime 이 모든 .NET 프로그래밍 언어들을 위한 공통 기반을 제공하고 있기 때문에 가능하다.


.NET Framework Tools.


.NET Framework 은 몇 개의 커맨드라인 도구들을 제공하는데, 이것들은 응용프로그램을 생성하는데 필요하다. 그 도구들 중에 는 Vbc.exe( Visual Basic Compiler ), Csc.exe( Visual C# compiler ), MSBuild.exe( the build engine for Visual Studio )와 같은 컴파일러들이 있다. 이러한 모든 도구들은 C:\Windows\Microsoft.NET\Framework\v4.0 폴더에 저장되어 있다. 대부분의 경우에, 당신은 직접 .NET Framework 도구들을 실행할 필요는 없다. 왜냐하면 당신은 Microsoft Visual Studio 2010 Integrated Development Environment 를 사용해서 작업을 할 거이고, 이는 필요할 때 적절한 도구를 실행해 줄 책임이 있기 때문이다. 우리가 아직 어떤 주제들에 대해서 이야기하지 않았기 때문에, 여기에서 모든 도구들을 나열하지는 않겠다. Visual Studio 에 의해 실행되는 .NET 도구들에 대한 정보에 대해서는 특정 도구들을 포함하는 특별한 주제를 논의할 때 이야기하는 것으로 한다.


Windows Software Development Kit.


Visual Studio 2008 부터, 설치 프로세스는 당신의 컴퓨터에 .NET Framework 와 개발 환경과 함께 Windows SDK 도 설치할 것이다. 이 software development kit 은 부가적인 도구들과 라이브러리들을 제공하는데, 이것들은 .NET Framework 을 위한 응용프로그램을 개발하는데 유용하다. 이전 버전의 .NET Framework 과 Microsoft Windows 운영체제에서는 당신이 두 개의 패키지를 설치해야만 했고, 예전에는 .NET Framework SDK 와 Microsoft Platform SDK 라고 불렸었다. Windows Vista 가 소개되면서, .NET Framework 은 운영체제의 코어중 일부가 되었다; Microsoft 는 Windows SDK 를 릴리즈했는데, 그것은 관리 및 비관리 응용프로그램 모두를 빌드하는데 사용되는 도구들을 제공한다. Windows SDK 는 C:\Program Files\Microsoft SDKs\Windows\v7.0A 폴더에 설치되는데, 이는 배포( deployment ), 코드 분석, Windows Communication Foundation 프로젝트를 위한 프락시( proxy ) 클래스 생성과 같은 어셈블리들을 빌드하는 작업들을 위해 Microsoft Visual Studio 에 의해서 사용되는 부가적인 도구들을 포함하고 있다. 또한 이 경우에도 당신은 이들 도구를 직접 실행할 필요가 없다. 왜냐하면 Visual Studio 가 당신을 위해서 이를 처리해 줄 것이기 때문이다. 적절한 장에서 Windows SDK 의 도구들에 대한 정보를 찾아볼 수 있다.


What's New in .NET Framework 4.0.


만약 당신이 .NET Framework 3.5 를 사용한 개발 경험을 가지고 있다면, 그것이 incremental architecture 를 가지고 있다는 것을 알고 있을 것이다. 이는 ( LINQ 와 같은 이 버전의 전통적인 기술들을 포함한 ) .NET 3.5 가 Windows Forms 와 같은 핵심 .NET 기능 및 기술들을 위해서 .NET 2.0 에 의존한다는 것을 의미한다. 반면에 Windows Presentation Foundation, Windows Workflow Foundation, CardSpace 등과 같은 framework 을 위해서는 .NET Framework 3.0 을 요구한다. 이는 .NET Framework 3.5 가 이전 버전이 prerequisite 로서 설치되어 있을 것을 요구한다는 것을 의미한다. .NET Framework 4.0 은 완전히 독립적인 기술이며, 이는 다른 버전이 설치될 것을 요구하지 않는다. .NET Framework 3.0, 3.5 에 대한 지식을 가지고 있다고 가정하고, 당신의 편의를 위해 .NET 4.5 에서 새롭게 추가된 기능을 정리했다 :

  • Windows Presentation Foundation.
  • Windows Communication Foundation.
  • ASP.NET( 이제 Ajax 와 MVC 를 포함 ).
  • ADO.NET Entity Framework.
  • Visual Studio Tools for Office.
  • Windows Workflow Foundation.

이 새로운 버전의 기술들은 단지 부가적인 기능을 추가한 것뿐만 아니라, 구조가 변경되고 개선되었다. .NET Framework 4.0 은 이전 버전에서 직접 설치해야만 했거나 .NET 3.5 Service Pack 1 의 일부였던 framework 들도 포함하고 있다 :

  • ADO.NET Data Services.
  • Parallel Extensions for the Task Parallel Library, or TPL for shot( related to the parallel computing ).
  • Code Contracts.

Windows Forms 기술은 여전히 .NET Framework 2.0 에 있다. 거기에는 얼마 안 되는 부가적인 사용자 컨트롤( user control )들만 있으며, 그것들은 30 장의 "Creating Windows Forms 4.0 Application" 에서 논의된다.


Summary.


.NET Framework 을 이해하는 것은 Visual Basic 2010 을 사용하여 응용프로그램을 개발하는데 있어서 매우 중요하다. 왜냐하면 당신은 .NET Framework 을 위한 응용프로그램을 빌드할 것이기 때문이다. 이 장은 Common Language Runtime 과 Base Class Library, 그리고 응용프로그램이 컴파일되고 실행되는 방식과 같은 .NET Framework 4.0 의 고수준 개관 및 핵심 개념들을 제공했다. 또한 가장 중요한 커맨드라인 도구들과 .NET 언어들에 대한 개관도 제공했다.


'Programming > .NET' 카테고리의 다른 글

[ 4 ] DataBinding  (0) 2012.10.14
[ 3 ] Dependency property.  (0) 2012.10.11
[ 2 ] XAML  (0) 2012.10.10
[ 1 ] WPF Architecture.  (0) 2012.10.08
[ 6 ] Proerty, indexer, attribute  (0) 2012.10.05
[ 5 ] Delegate and event.  (0) 2012.10.02
[ 4 ] Classes and structs  (0) 2012.09.27
Extension Methods  (0) 2012.09.26
[ 3 ] .NET Garbage Collection.  (0) 2012.09.25
[ 2 ] C# Types  (0) 2012.09.25

"응용 컴퓨터 과학을 위한 문제 해결 기법" 이라는 제목을 가지고 있는 수업의 사이트이다. 2010 년에 한 수업인거 같은데 많은 자료들이 있어 도움이 된다. Handouts 라는 메뉴에 들어가면 수업에서 사용했던  자료들이 PDF 로 정리되어 있는데 매우 좋다.

Syllabus( 교수안 )에서 소개하는 수업의 내용은 다음과 같다.

이 과정은 알고리즘, 응용 수학, 기하학 중에서 몇 개의 주제를 다루는데, 이들은 geometric modeling, graphics, robotics, vision, human machine interface, speed recognition, computer animation 등과 같은 영역의 응용프로그램에서 찾아볼 수 있는 것들이다
http://www.cs.iastate.edu/~cs577/

'ETC' 카테고리의 다른 글

before-after plugin test  (0) 2017.07.23
[ TIP ] Visual Sutdio 환경 설정 공유  (0) 2017.05.20
Behavior Tree 개념 및 동작  (6) 2016.06.02
[ 번역 ] 와우 전투 시스템  (0) 2015.11.27
The activity diagram  (0) 2014.10.15
발음 기호를 제대로 익힐 수 있는 사이트.  (0) 2012.02.22
SyntaxHighlighter test.  (0) 2011.03.01

아이오와 주립대에는 발음기호를 제대로 익힐 수 있도록 동영상을 보여 주는 사이트가 있다. 지금까지 한글로 대충 적어 놓은 발음 기호들의 차이가 뭔지 알기 어려웠었는데, 이 사이트를 보면서 많은 도움을 받았다.

http://www.uiowa.edu/~acadtech/phonetics/english/frameset.html

'ETC' 카테고리의 다른 글

before-after plugin test  (0) 2017.07.23
[ TIP ] Visual Sutdio 환경 설정 공유  (0) 2017.05.20
Behavior Tree 개념 및 동작  (6) 2016.06.02
[ 번역 ] 와우 전투 시스템  (0) 2015.11.27
The activity diagram  (0) 2014.10.15
응용 수학에 대해서 참고할 만한 사이트.  (0) 2012.02.22
SyntaxHighlighter test.  (0) 2011.03.01
PRE
/**
 * Test class.
*/
class TestClass
{
public :

	/**
	 * 생성자.
	*/
	TestClass()
		: mValue( 0 )
	{
		
	}

	/**
	 * 소멸자.
	*/
	~TestClass()
	{
		
	}

	/**
	 * value 를 획득한다.
	 * @return value.
	*/
	int getValue(){	return mValue;	}

private:

	int mValue;	///< value.
};
TEXTAREA OL
  1. /**
  2. * Test class.
  3. */
  4. class TestClass
  5. {
  6. public :
  7. /**
  8. * 생성자.
  9. */
  10. TestClass()
  11. : mValue( 0 )
  12. {
  13. }
  14. /**
  15. * 소멸자.
  16. */
  17. ~TestClass()
  18. {
  19. }
  20. /**
  21. * value 를 획득한다.
  22. * @return value.
  23. */
  24. int getValue(){ return mValue; }
  25. private:
  26. int mValue; ///< value.
  27. };
OL 은 일반 html tag 라 역시 tab 이 다 날라가는군...

 

일단 "Graphic card 를 만드는 제조사에 종속되지 않도록, 순수 OpenCL 을 설치해 보겠어!!!" 라는 다짐을 하고 계신 분이 있다면 말리고 싶다. 아니 불가능하다고 말하고 싶다. 왜냐하면 Khronos group 은 단지 specification 만을 제공하기 때문이다. Khronos 의 OpenCL page 에 가면 header file 은 있는데, source file 이 없다는 데 대해 엄청난 의아함을 느끼게 된다. 나도 source file 찾아보려고 노력해 봤는데, 절대 없었다.

 

단순한 이유다. 이전 글에서도 언급했듯이, Khronos group 에서 제공하는 표준을 구현하는 것은 driver 제조 업체별로 이루어지는 일이기 때문에 source file 이 있으면 그게 더 이상한거다.

 

결국 AMD/ATI card 를 사용하는 사람은 Stream SDK 를 NVidia card 를 사용하는 사람은 CUDA toolkit 을 깔지 않으면 안 되는 상황이 된다. 그리고 구현하는 입장에서도 NVidia 용이냐 AMD/ATI 용이냐에 따라서 서로 다른 실행 파일을 제공해야 한다. 여기에서는 NVidia 를 기준으로 설명하도록 하겠다.

 

일단 http://developer.nvidia.com/ 로 가서 Cuda toolkit page 로 이동한 다음, 자신의 OS 에 맞는 Cuda toolkit 용 graphic card driver 와 CUDA toolkit 을 download 한다. 그리고 그것을 설치한다. 그리고 CUDA toolkit 이 설치된 경로를 확인한다.

 

예를 들어 CUDA 같은 경우에는 다음과 같은 경로에서 OpenCL 의 header 와 library 를 찾을 수 있다.

 

C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v3.2\include

C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v3.2\lib

 

물론 이 경우는 내 machine 에서의 설치 경로이기 때문에 다른 사람들은 자신만의 경로를 지정해야만 할 것이다.

 

위의 경로를 visual studio 의 VC++ Directories 항목에 추가해 준 다음에 source code 에 다음과 같이 입력하면, OpenCL 을 사용할 준비를 마친 것이다.

 

#include < CL/cl.h >

#pragma comment( lib, "OpenCL" )

 

물론 lib 를 project 속성에서 넣어도 상관은 없다. 이것은 NVidia 나 AMD/ATI 나 동일한 식으로 하면 되는 것으로 알고 있다.

 

해 보진 않았지만 program 의 호환성 보장을 위해서는 NVidiaOpenCL.dll, ATIOpenCL.dll 같은 wrapper 를 따로 만들어서 실행시에 동적으로 loading 할 수 있도록 하는 것이 좋을 것 같다.




최근에 multi-platform platform 에 대응하는 OpenCL 관리자를 만들려고 하다가 보니 모든 종류의 platform 에 대한 lib 를 수집해야 한다는 문제가 발생했다. 예를 들면 다음과 같은 조합이 필요하다.


  • 제조사 : AMD, Intel, NVida.
  • 기기 : Desktop, Notebook.
  • 운영체제 : Windows XP, Windows 7.


물론 더 많은 제조사가 존재하겠지만 게임이 돌아 갈 만한 환경은 저 정도가 되겠다. 이 경우 3 X 2 X 2 = 12 개의 조합이 나온다. 아무리 생각해도 이건 좀 아니다 싶은 상황이 되었다.


모든 platform 에서 돌아 갈 수 있는 프로그램을 만들기 위해서는 좀 더 많은 고민이 필요할 것 같다.




OpenCL.lib 는 static library 가 아니고 import library 였다. Multi-platform 에 대응하기 위해서는 해당 platform 을 위해 배포된 OpenCL.dll 을 직접 LoadLibrary() 로 부른 다음에 GetModuleHandle() 을 통해서 API 를 획득하는 방식을 취해야 할 것 같다.


+ Recent posts