COM을 사용하여 DirectX 프로그래밍
MICROSOFT COM(구성 요소 개체 모델)은 DirectX API 표면의 대부분을 포함하여 여러 기술에서 사용하는 개체 지향 프로그래밍 모델입니다. 이러한 이유로 DirectX 개발자는 DirectX를 프로그래밍할 때 필연적으로 COM을 사용합니다.
참고
C++/WinRT를 사용하여 COM 구성 요소 사용 항목에서는 C++/WinRT를 사용하여 DirectX API(및 해당 문제에 대한 모든 COM API)를 사용하는 방법을 보여 줍니다. 이는 지금까지 가장 편리하고 권장되는 기술입니다.
또는 원시 COM을 사용할 수 있으며, 이것이 이 항목의 내용입니다. COM API 사용과 관련된 원칙 및 프로그래밍 기술에 대한 기본적인 이해가 필요합니다. COM은 어렵고 복잡하다는 평판을 가지고 있지만 대부분의 DirectX 애플리케이션에 필요한 COM 프로그래밍은 간단합니다. 이는 DirectX에서 제공하는 COM 개체를 소비하기 때문입니다. 일반적으로 복잡성이 발생하는 COM 개체를 직접 작성할 필요가 없습니다.
COM 구성 요소 개요
COM 개체는 기본적으로 애플리케이션에서 하나 이상의 작업을 수행하는 데 사용할 수 있는 기능의 캡슐화된 구성 요소입니다. 배포의 경우 하나 이상의 COM 구성 요소가 COM 서버라는 이진 파일로 패키지됩니다. DLL이 아닌 경우가 많습니다.
기존 DLL은 자유 함수를 내보냅니다. COM 서버도 동일한 작업을 수행할 수 있습니다. 그러나 COM 서버 내의 COM 구성 요소는 해당 인터페이스에 속하는 COM 인터페이스 및 멤버 메서드를 노출합니다. 애플리케이션은 COM 구성 요소의 인스턴스를 만들고, 해당 구성 요소에서 인터페이스를 검색하고, COM 구성 요소에서 구현된 기능을 활용하기 위해 해당 인터페이스에서 메서드를 호출합니다.
실제로 일반 C++ 개체에서 메서드를 호출하는 것과 비슷합니다. 그러나 몇 가지 차이점이 있습니다.
- COM 개체는 C++ 개체보다 더 엄격한 캡슐화를 적용합니다. 개체를 만든 다음 공용 메서드를 호출할 수 없습니다. 대신 COM 구성 요소의 공용 메서드는 하나 이상의 COM 인터페이스로 그룹화됩니다. 메서드를 호출하려면 개체를 만들고 메서드를 구현하는 인터페이스를 개체에서 검색합니다. 인터페이스는 일반적으로 개체의 특정 기능에 대한 액세스를 제공하는 관련 메서드 집합을 구현합니다. 예를 들어 ID3D12Device 인터페이스는 가상 그래픽 어댑터를 나타내며 리소스를 만들 수 있는 메서드(예: 및 기타 여러 어댑터 관련 작업)를 포함합니다.
- COM 개체는 C++ 개체와 동일한 방식으로 만들어지지 않습니다. COM 개체를 만드는 방법에는 여러 가지가 있지만 모두 COM 관련 기술이 포함됩니다. DirectX API에는 대부분의 DirectX COM 개체 만들기를 간소화하는 다양한 도우미 함수와 메서드가 포함되어 있습니다.
- COM 개체의 수명을 제어하려면 COM 관련 기술을 사용해야 합니다.
- COM 서버(일반적으로 DLL)는 명시적으로 로드할 필요가 없습니다. 또한 COM 구성 요소를 사용하기 위해 정적 라이브러리에 연결하지 않습니다. 각 COM 구성 요소에는 애플리케이션이 COM 개체를 식별하는 데 사용하는 고유한 등록된 식별자(전역적으로 고유한 식별자 또는 GUID)가 있습니다. 애플리케이션은 구성 요소를 식별하고 COM 런타임은 올바른 COM 서버 DLL을 자동으로 로드합니다.
- COM은 이진 사양입니다. COM 개체는 다양한 언어로 작성하고 액세스할 수 있습니다. 개체의 소스 코드에 대해 아무것도 알 필요가 없습니다. 예를 들어 Visual Basic 애플리케이션은 C++로 작성된 COM 개체를 정기적으로 사용합니다.
구성 요소, 개체 및 인터페이스
구성 요소, 개체 및 인터페이스 간의 차이점을 이해하는 것이 중요합니다. 일반 사용에서는 주 인터페이스의 이름으로 참조되는 구성 요소 또는 개체가 들릴 수 있습니다. 그러나 용어는 서로 교환 할 수 없습니다. 구성 요소는 여러 인터페이스를 구현할 수 있습니다. 및 개체는 구성 요소의 instance. 예를 들어 모든 구성 요소는 IUnknown 인터페이스를 구현해야 하지만 일반적으로 하나 이상의 추가 인터페이스를 구현하며 많은 인터페이스를 구현할 수 있습니다.
특정 인터페이스 메서드를 사용하려면 개체를 인스턴스화할 뿐만 아니라 올바른 인터페이스도 가져와야 합니다.
또한 둘 이상의 구성 요소가 동일한 인터페이스를 구현할 수 있습니다. 인터페이스는 논리적으로 관련된 작업 집합을 수행하는 메서드 그룹입니다. 인터페이스 정의는 메서드의 구문과 해당 일반 기능만 지정합니다. 특정 작업 집합을 지원해야 하는 모든 COM 구성 요소는 적절한 인터페이스를 구현하여 수행할 수 있습니다. 일부 인터페이스는 고도로 특수화되며 단일 구성 요소에서만 구현됩니다. 다른 항목은 다양한 상황에서 유용하며 많은 구성 요소에서 구현됩니다.
구성 요소가 인터페이스를 구현하는 경우 인터페이스 정의의 모든 메서드를 지원해야 합니다. 즉, 메서드를 호출할 수 있어야 하며 메서드가 존재한다는 것을 확신할 수 있어야 합니다. 그러나 특정 메서드를 구현하는 방법에 대한 세부 정보는 구성 요소마다 다를 수 있습니다. 예를 들어 다른 구성 요소는 다른 알고리즘을 사용하여 최종 결과에 도달할 수 있습니다. 메서드가 사소한 방식으로 지원된다는 보장도 없습니다. 경우에 따라 구성 요소는 일반적으로 사용되는 인터페이스를 구현하지만 메서드의 하위 집합만 지원해야 합니다. 나머지 메서드는 여전히 성공적으로 호출할 수 있지만 값 E_NOTIMPL 포함하는 HRESULT(결과 코드를 나타내는 표준 COM 형식)를 반환합니다. 특정 구성 요소에서 인터페이스를 구현하는 방법을 보려면 해당 설명서를 참조해야 합니다.
COM 표준을 사용하려면 인터페이스 정의가 게시된 후에는 변경되지 않아야 합니다. 예를 들어 작성자가 기존 인터페이스에 새 메서드를 추가할 수 없습니다. 작성자는 대신 새 인터페이스를 만들어야 합니다. 해당 인터페이스에 있어야 하는 메서드에 대한 제한은 없지만, 일반적인 방법은 차세대 인터페이스에 이전 인터페이스의 모든 메서드와 새 메서드를 포함하는 것입니다.
인터페이스에 여러 세대가 있는 것은 드문 일이 아닙니다. 일반적으로 모든 세대는 기본적으로 동일한 전체 작업을 수행하지만 구체적으로는 다릅니다. COM 구성 요소는 지정된 인터페이스 계보의 모든 현재 및 이전 세대를 구현하는 경우가 많습니다. 이렇게 하면 이전 애플리케이션에서 개체의 이전 인터페이스를 계속 사용할 수 있지만 최신 애플리케이션은 최신 인터페이스의 기능을 활용할 수 있습니다. 일반적으로 인터페이스의 하강 그룹은 모두 이름이 같고 생성을 나타내는 정수도 있습니다. 예를 들어 원래 인터페이스 이름이 IMyInterface (1세대를 의미함)인 경우 다음 두 세대를 IMyInterface2 및 IMyInterface3이라고 합니다. DirectX 인터페이스의 경우 연속 세대는 일반적으로 DirectX 버전 번호의 이름을 지정합니다.
GUID
GUID는 COM 프로그래밍 모델의 핵심 부분입니다. 가장 기본적인 GUID는 128비트 구조체입니다. 그러나 GUID는 두 GUID가 동일하지 않음을 보장하는 방식으로 만들어집니다. COM은 두 가지 기본 용도로 GUID를 광범위하게 사용합니다.
- 특정 COM 구성 요소를 고유하게 식별합니다. COM 구성 요소를 식별하기 위해 할당된 GUID를 CLSID(클래스 식별자)라고 하며, 연결된 COM 구성 요소의 instance 만들 때 CLSID를 사용합니다.
- 특정 COM 인터페이스를 고유하게 식별합니다. COM 인터페이스를 식별하기 위해 할당된 GUID를 IID(인터페이스 식별자)라고 하며, 구성 요소(개체)의 instance 특정 인터페이스를 요청할 때 IID를 사용합니다. 인터페이스의 IID는 인터페이스를 구현하는 구성 요소에 관계없이 동일합니다.
편의를 위해 DirectX 설명서는 일반적으로 GUID가 아닌 설명이 포함된 이름(예: ID3D12Device)으로 구성 요소 및 인터페이스를 참조합니다. DirectX 설명서의 컨텍스트 내에서는 모호성이 없습니다. 기술적으로 타사에서 ID3D12Device 라는 설명이 포함된 인터페이스를 작성할 수 있습니다(유효하려면 다른 IID가 있어야 합니다). 하지만 명확성을 위해 권장되지 않습니다.
따라서 특정 개체 또는 인터페이스를 참조하는 유일한 명확한 방법은 GUID를 사용하는 것입니다.
GUID는 구조체이지만 GUID는 종종 동등한 문자열 형식으로 표현됩니다. GUID 문자열 형식의 일반 형식은 8-4-4-4-12 형식의 326진수입니다. 즉, {xxxxxxxx-xxxx-xxxx-xxxx-xxxx-xxxxxxxxxx}입니다. 여기서 각 x는 16진수에 해당합니다. 예를 들어 ID3D12Device 인터페이스에 대한 IID의 문자열 형식은 {189819F1-1DB6-4B57-BE54-1821339B85F7}입니다.
실제 GUID는 사용하기가 다소 서투르고 잘못 입력하기 쉽기 때문에 일반적으로 동일한 이름도 제공됩니다. 코드에서 함수를 호출할 때 실제 구조 대신 이 이름을 사용할 수 있습니다( 예: 매개 변수에 대한 riid 인수를 D3D12CreateDevice에 전달할 때). 사용자 지정 명명 규칙은 각각 인터페이스 또는 개체의 설명이 포함된 이름에 IID_ 또는 CLSID_ 앞에 추가하는 것입니다. 예를 들어 ID3D12Device 인터페이스의 IID 이름은 IID_ID3D12Device.
참고
DirectX 애플리케이션은 및 uuid.lib 와 dxguid.lib 연결하여 다양한 인터페이스 및 클래스 GUID에 대한 정의를 제공해야 합니다. Visual C++ 및 기타 컴파일러에서는 __uuidof 연산자 언어 확장을 지원하지만 이러한 링크 라이브러리와의 명시적 C 스타일 연결도 지원되고 완전히 이식 가능합니다.
HRESULT 값
대부분의 COM 메서드는 HRESULT라는 32비트 정수 를 반환합니다. 대부분의 메서드에서 HRESULT는 기본적으로 두 가지 기본 정보를 포함하는 구조체입니다.
- 메서드가 성공했는지 또는 실패했는지 여부입니다.
- 메서드에서 수행하는 작업의 결과에 대한 자세한 정보입니다.
일부 메서드는 에 정의된 표준 집합에서 HRESULT 값을 반환합니다 Winerror.h. 그러나 메서드는 보다 특수화된 정보를 사용하여 사용자 지정 HRESULT 값을 자유롭게 반환할 수 있습니다. 이러한 값은 일반적으로 메서드의 참조 페이지에 설명되어 있습니다.
메서드의 참조 페이지에서 찾은 HRESULT 값 목록은 종종 반환될 수 있는 가능한 값의 하위 집합일 뿐입니다. 이 목록에는 일반적으로 메서드와 관련된 값과 메서드 관련 의미가 있는 표준 값만 포함됩니다. 메서드가 명시적으로 문서화되지 않은 경우에도 다양한 표준 HRESULT 값을 반환할 수 있다고 가정해야 합니다.
HRESULT 값은 오류 정보를 반환하는 데 자주 사용되지만 오류 코드로 간주해서는 안 됩니다. 성공 또는 실패를 나타내는 비트가 자세한 정보를 포함하는 비트와 별도로 저장된다는 사실은 HRESULT 값에 성공 및 실패 코드 수를 포함할 수 있습니다. 규칙에 따라 성공 코드의 이름은 E_ S_ 및 실패 코드로 접두사로 지정됩니다. 예를 들어 가장 일반적으로 사용되는 두 코드는 각각 간단한 성공 또는 실패를 나타내는 S_OK 및 E_FAIL.
COM 메서드가 다양한 성공 또는 실패 코드를 반환할 수 있다는 사실은 HRESULT 값을 테스트하는 방법에 주의해야 한다는 것을 의미합니다. 예를 들어 성공한 경우 문서화된 반환 값이 S_OK 가상 메서드를 사용하고 그렇지 않은 경우 E_FAIL 고려합니다. 그러나 메서드는 다른 실패 또는 성공 코드도 반환할 수 있습니다. 다음 코드 조각은 메서드에서 반환된 HRESULT 값을 포함하는 간단한 테스트를 hr 사용할 때의 위험을 보여 줍니다.
if (hr == E_FAIL)
{
// Handle the failure case.
}
else
{
// Handle the success case.
}
실패 사례에서 이 메서드는 다른 오류 코드가 아닌 E_FAIL 반환하는 한 이 테스트가 작동합니다. 그러나 특정 오류 코드 집합(E_NOTIMPL 또는 E_INVALIDARG)을 반환하기 위해 지정된 메서드가 구현되는 것이 더 현실적입니다. 위의 코드를 사용하면 이러한 값이 성공으로 잘못 해석됩니다.
메서드 호출의 결과에 대한 자세한 정보가 필요한 경우 각 관련 HRESULT 값을 테스트해야 합니다. 그러나 메서드가 성공했는지 실패했는지에만 관심이 있을 수 있습니다. HRESULT 값이 성공 또는 실패를 나타내는지 여부를 테스트하는 강력한 방법은 Winerror.h에 정의된 다음 매크로 중 하나에 값을 전달하는 것입니다.
- 매크로는
SUCCEEDED성공 코드에 대해 TRUE를 반환하고 실패 코드의 경우 FALSE를 반환합니다. - 매크로는
FAILED실패 코드에 대해 TRUE를 반환하고 성공 코드의 경우 FALSE를 반환합니다.
따라서 다음 코드와 같이 매크로를 사용하여 FAILED 이전 코드 조각을 수정할 수 있습니다.
if (FAILED(hr))
{
// Handle the failure case.
}
else
{
// Handle the success case.
}
이 수정된 코드 조각은 E_NOTIMPL 및 E_INVALIDARG 오류로 올바르게 처리합니다.
대부분의 COM 메서드는 구조화된 HRESULT 값을 반환하지만 소수의 경우 HRESULT 를 사용하여 단순 정수를 반환합니다. 암시적으로 이러한 메서드는 항상 성공합니다. 이 정렬의 HRESULT 를 SUCCEEDED 매크로에 전달하면 매크로는 항상 TRUE를 반환합니다. HRESULT를 반환하지 않는 일반적으로 호출되는 메서드의 예는 ULONG을 반환하는 IUnknown::Release 메서드입니다. 이 메서드는 개체의 참조 수를 1씩 감소시키고 현재 참조 수를 반환합니다. 참조 계산에 대한 설명은 COM 개체의 수명 관리를 참조하세요.
포인터의 주소
몇 가지 COM 메서드 참조 페이지를 보는 경우 다음과 같은 항목을 실행할 수 있습니다.
HRESULT D3D12CreateDevice(
IUnknown *pAdapter,
D3D_FEATURE_LEVEL MinimumFeatureLevel,
REFIID riid,
void **ppDevice
);
일반 포인터는 C/C++ 개발자에게 매우 친숙하지만 COM은 종종 추가 수준의 간접 참조를 사용합니다. 이 두 번째 수준의 간접 참조는 형식 선언에 따라 두 개의 별표로 **표시되며 변수 이름에는 일반적으로 접두 pp사 가 있습니다. 위의 함수의 경우 매개 변수를 ppDevice 일반적으로 void에 대한 포인터의 주소라고 합니다. 실제로 이 예제 ppDevice 에서는 ID3D12Device 인터페이스에 대한 포인터의 주소입니다.
C++ 개체와 달리 COM 개체의 메서드에 직접 액세스하지 않습니다. 대신 메서드를 노출하는 인터페이스에 대한 포인터를 가져와야 합니다. 메서드를 호출하려면 기본적으로 C++ 메서드에 대한 포인터를 호출하는 것과 동일한 구문을 사용합니다. 예를 들어 IMyInterface::D oSomething 메서드를 호출하려면 다음 구문을 사용합니다.
IMyInterface * pMyIface = nullptr;
...
pMyIface->DoSomething(...);
두 번째 수준의 간접 참조는 인터페이스 포인터를 직접 만들지 않는다는 사실에서 비롯됩니다. 위에 표시된 D3D12CreateDevice 메서드와 같은 다양한 메서드 중 하나를 호출해야 합니다. 이러한 메서드를 사용하여 인터페이스 포인터를 가져오려면 변수를 원하는 인터페이스에 대한 포인터로 선언한 다음 해당 변수의 주소를 메서드에 전달합니다. 즉, 포인터의 주소를 메서드에 전달합니다. 메서드가 반환되면 변수는 요청된 인터페이스를 가리키며 해당 포인터를 사용하여 인터페이스의 메서드를 호출할 수 있습니다.
IDXGIAdapter * pIDXGIAdapter = nullptr;
...
ID3D12Device * pD3D12Device = nullptr;
HRESULT hr = ::D3D12CreateDevice(
pIDXGIAdapter,
D3D_FEATURE_LEVEL_11_0,
IID_ID3D12Device,
&pD3D12Device);
if (FAILED(hr)) return E_FAIL;
// Now use pD3D12Device in the form pD3D12Device->MethodName(...);
COM 개체 만들기
COM 개체를 만드는 방법에는 여러 가지가 있습니다. DirectX 프로그래밍에서 가장 일반적으로 사용되는 두 가지 항목입니다.
- 간접적으로 개체를 만드는 DirectX 메서드 또는 함수를 호출합니다. 메서드는 개체를 만들고 개체에 대한 인터페이스를 반환합니다. 이러한 방식으로 개체를 만들 때 반환할 인터페이스를 지정할 수도 있고 인터페이스가 암시된 경우도 있습니다. 위의 코드 예제에서는 Direct3D 12 디바이스 COM 개체를 간접적으로 만드는 방법을 보여줍니다.
- 개체의 CLSID를 CoCreateInstance 함수에 직접 전달합니다. 함수는 개체의 instance 만들고 지정한 인터페이스에 대한 포인터를 반환합니다.
한 번은 COM 개체를 만들기 전에 CoInitializeEx 함수를 호출하여 COM을 초기화해야 합니다. 개체를 간접적으로 만드는 경우 개체 만들기 메서드가 이 작업을 처리합니다. 그러나 CoCreateInstance를 사용하여 개체를 만들어야 하는 경우 CoInitializeEx를 명시적으로 호출해야 합니다. 완료되면 CoUninitialize를 호출하여 COM을 초기화하지 않아야 합니다. CoInitializeEx를 호출하는 경우 CoUninitialize 호출과 일치해야 합니다. 일반적으로 COM을 명시적으로 초기화해야 하는 애플리케이션은 시작 루틴에서 이 작업을 수행하며 정리 루틴에서 COM을 초기화하지 않습니다.
CoCreateInstance를 사용하여 COM 개체의 새 instance 만들려면 개체의 CLSID가 있어야 합니다. 이 CLSID를 공개적으로 사용할 수 있는 경우 참조 설명서 또는 적절한 헤더 파일에서 찾을 수 있습니다. CLSID를 공개적으로 사용할 수 없는 경우 개체를 직접 만들 수 없습니다.
CoCreateInstance 함수에는 5개의 매개 변수가 있습니다. DirectX에서 사용할 COM 개체의 경우 일반적으로 다음과 같이 매개 변수를 설정할 수 있습니다.
rclsid 만들려는 개체의 CLSID로 설정합니다.
pUnkOuter 를 로 nullptr설정합니다. 이 매개 변수는 개체를 집계하는 경우에만 사용됩니다. COM 집계에 대한 논의는 이 항목의 scope 외부에 있습니다.
dwClsContext 를 CLSCTX_INPROC_SERVER. 이 설정은 개체가 DLL로 구현되고 애플리케이션 프로세스의 일부로 실행됨을 나타냅니다.
Riid 반환하려는 인터페이스의 IID로 설정합니다. 함수는 개체를 만들고 ppv 매개 변수에 요청된 인터페이스 포인터를 반환합니다.
Ppv 함수가 반환될 때 에 지정된 인터페이스로 설정되는 포인터의 주소로 riid 설정합니다. 이 변수는 요청된 인터페이스에 대한 포인터로 선언되어야 하며 매개 변수 목록의 포인터에 대한 참조는 (LPVOID *)로 캐스팅되어야 합니다.
위의 코드 예제에서 보았듯이 일반적으로 개체를 간접적으로 만드는 것이 훨씬 간단합니다. 개체 만들기 메서드에 인터페이스 포인터의 주소를 전달한 다음, 메서드는 개체를 만들고 인터페이스 포인터를 반환합니다. 개체를 간접적으로 만들 때 메서드가 반환하는 인터페이스를 선택할 수 없는 경우에도 개체를 만드는 방법에 대한 다양한 항목을 지정할 수 있는 경우가 많습니다.
예를 들어 위의 코드 예제와 같이 반환된 디바이스에서 지원해야 하는 최소 D3D 기능 수준을 지정하는 값을 D3D12CreateDevice 에 전달할 수 있습니다.
COM 인터페이스 사용
COM 개체를 만들 때 생성 메서드는 인터페이스 포인터를 반환합니다. 그런 다음, 해당 포인터를 사용하여 인터페이스의 메서드에 액세스할 수 있습니다. 구문은 C++ 메서드에 대한 포인터와 함께 사용되는 구문과 동일합니다.
추가 인터페이스 요청
대부분의 경우 생성 메서드에서 수신하는 인터페이스 포인터가 필요한 유일한 포인터일 수 있습니다. 실제로 개체는 IUnknown 이외의 인터페이스 하나만 내보내는 것이 비교적 일반적입니다. 그러나 많은 개체가 여러 인터페이스를 내보내고 그 중 몇 가지에 대한 포인터가 필요할 수 있습니다. 생성 메서드에서 반환된 인터페이스보다 더 많은 인터페이스가 필요한 경우 새 개체를 만들 필요가 없습니다. 대신 개체의 IUnknown::QueryInterface 메서드를 사용하여 다른 인터페이스 포인터를 요청합니다.
CoCreateInstance를 사용하여 개체를 만드는 경우 IUnknown 인터페이스 포인터를 요청한 다음, IUnknown::QueryInterface를 호출하여 필요한 모든 인터페이스를 요청할 수 있습니다. 그러나 이 방법은 단일 인터페이스만 필요한 경우 불편하며 반환할 인터페이스 포인터를 지정할 수 없는 개체 만들기 메서드를 사용하는 경우 전혀 작동하지 않습니다. 실제로는 모든 COM 인터페이스가 IUnknown 인터페이스를 확장하므로 명시적 IUnknown 포인터를 가져올 필요가 없습니다.
인터페이스 확장은 개념적으로 C++ 클래스에서 상속하는 것과 비슷합니다. 자식 인터페이스는 부모 인터페이스의 모든 메서드와 하나 이상의 자체 메서드를 노출합니다. 실제로 "extends" 대신 "상속"이 사용되는 경우가 많습니다. 기억해야 할 것은 상속이 개체 내부라는 것입니다. 애플리케이션은 개체의 인터페이스에서 상속하거나 확장할 수 없습니다. 그러나 자식 인터페이스를 사용하여 자식 또는 부모의 메서드를 호출할 수 있습니다.
모든 인터페이스는 IUnknown의 자식이므로 개체에 대해 이미 있는 인터페이스 포인터에서 QueryInterface 를 호출할 수 있습니다. 이렇게 하면 요청하는 인터페이스의 IID와 메서드가 반환될 때 인터페이스 포인터를 포함할 포인터의 주소를 제공해야 합니다.
예를 들어 다음 코드 조각은 IDXGIFactory2::CreateSwapChainForHwnd 를 호출하여 기본 스왑 체인 개체를 만듭니다. 이 개체는 여러 인터페이스를 노출합니다. CreateSwapChainForHwnd 메서드는 IDXGISwapChain1 인터페이스를 반환합니다. 그런 다음, 후속 코드는 IDXGISwapChain1 인터페이스를 사용하여 QueryInterface 를 호출하여 IDXGISwapChain3 인터페이스를 요청합니다.
HRESULT hr = S_OK;
IDXGISwapChain1 * pDXGISwapChain1 = nullptr;
hr = pIDXGIFactory->CreateSwapChainForHwnd(
pCommandQueue, // For D3D12, this is a pointer to a direct command queue.
hWnd,
&swapChainDesc,
nullptr,
nullptr,
&pDXGISwapChain1));
if (FAILED(hr)) return hr;
IDXGISwapChain3 * pDXGISwapChain3 = nullptr;
hr = pDXGISwapChain1->QueryInterface(IID_IDXGISwapChain3, (LPVOID*)&pDXGISwapChain3);
if (FAILED(hr)) return hr;
참고
C++에서는 명시적 IID 및 캐스트 포인터 pDXGISwapChain1->QueryInterface(IID_PPV_ARGS(&pDXGISwapChain3));대신 매크로를 사용할 IID_PPV_ARGS 수 있습니다.
이는 QueryInterface뿐만 아니라 생성 메서드에도 자주 사용됩니다. 자세한 내용은 combaseapi.h 를 참조하세요.
COM 개체의 수명 관리
개체를 만들 때 시스템은 필요한 메모리 리소스를 할당합니다. 개체가 더 이상 필요하지 않으면 제거해야 합니다. 시스템은 다른 용도로 해당 메모리를 사용할 수 있습니다. C++ 개체를 사용하면 해당 수준에서 작업하는 경우나 스택 및 scope 수명을 사용하여 및 delete 연산자를 사용하여 개체의 수명을 직접 new 제어할 수 있습니다. COM에서는 개체를 직접 만들거나 삭제할 수 없습니다. 이 디자인의 이유는 동일한 개체를 애플리케이션의 둘 이상의 부분에서 사용하거나 경우에 따라 둘 이상의 애플리케이션에서 사용할 수 있기 때문입니다. 이러한 참조 중 하나가 개체를 삭제하는 경우 다른 참조는 유효하지 않습니다. 대신 COM은 참조 계산 시스템을 사용하여 개체의 수명을 제어합니다.
개체의 참조 수는 해당 인터페이스 중 하나가 요청된 횟수입니다. 인터페이스가 요청될 때마다 참조 수가 증가합니다. 애플리케이션은 해당 인터페이스가 더 이상 필요하지 않을 때 인터페이스를 해제하여 참조 횟수를 감소합니다. 참조 수가 0보다 크면 개체가 메모리에 남아 있습니다. 참조 수가 0에 도달하면 개체 자체가 삭제됩니다. 개체의 참조 수에 대해 아무것도 알 필요가 없습니다. 개체의 인터페이스를 제대로 가져오고 해제하는 한 개체의 수명은 적절합니다.
참조 계산을 올바르게 처리하는 것은 COM 프로그래밍의 중요한 부분입니다. 이렇게 하지 않으면 메모리 누수 또는 크래시가 쉽게 발생할 수 있습니다. COM 프로그래머가 하는 가장 일반적인 실수 중 하나는 인터페이스를 해제하지 못하는 것입니다. 이 경우 참조 수가 0에 도달하지 않으며 개체는 메모리에 무기한 유지됩니다.
참고
Direct3D 10 이상에는 개체에 대한 수명 규칙이 약간 수정되었습니다. 특히 ID3DxxDeviceChild 에서 파생된 개체는 부모 디바이스보다 오래 지속되지 않습니다(즉, 소유 ID3DxxDevice 가 0개의 refcount에 도달하면 모든 자식 개체도 즉시 유효하지 않습니다). 또한 Set 메서드를 사용하여 개체를 렌더링 파이프라인에 바인딩하는 경우 이러한 참조는 참조 횟수를 증가하지 않습니다(즉, 약한 참조임). 실제로 디바이스를 해제하기 전에 모든 디바이스 자식 개체를 완전히 해제하도록 하는 것이 가장 좋습니다.
참조 횟수 증가 및 감소
새 인터페이스 포인터를 가져올 때마다 IUnknown::AddRef를 호출하여 참조 횟수를 증분해야 합니다. 그러나 애플리케이션은 일반적으로 이 메서드를 호출할 필요가 없습니다. 개체 만들기 메서드를 호출하거나 IUnknown::QueryInterface를 호출하여 인터페이스 포인터를 가져오는 경우 개체는 자동으로 참조 횟수를 증가합니다. 그러나 기존 포인터 복사와 같은 다른 방법으로 인터페이스 포인터를 만드는 경우 IUnknown::AddRef를 명시적으로 호출해야 합니다. 그렇지 않으면 원래 인터페이스 포인터를 해제할 때 포인터의 복사본을 사용해야 하는 경우에도 개체가 제거될 수 있습니다.
사용자 또는 개체가 참조 횟수를 증가시켰는지 여부에 관계없이 모든 인터페이스 포인터를 해제해야 합니다. 인터페이스 포인터가 더 이상 필요하지 않은 경우 IUnknown::Release 를 호출하여 참조 횟수를 줄입니다. 일반적인 방법은 에 대한 모든 인터페이스 포인터를 nullptr초기화한 다음 해제될 때 로 다시 nullptr 설정하는 것입니다. 이 규칙을 사용하면 정리 코드의 모든 인터페이스 포인터를 테스트할 수 있습니다. 아직 활성화되지 않은 nullptr 항목은 애플리케이션을 종료하기 전에 해제해야 합니다.
다음 코드 조각은 참조 계산을 처리하는 방법을 설명하기 위해 앞에서 보여 준 샘플을 확장합니다.
HRESULT hr = S_OK;
IDXGISwapChain1 * pDXGISwapChain1 = nullptr;
hr = pIDXGIFactory->CreateSwapChainForHwnd(
pCommandQueue, // For D3D12, this is a pointer to a direct command queue.
hWnd,
&swapChainDesc,
nullptr,
nullptr,
&pDXGISwapChain1));
if (FAILED(hr)) return hr;
IDXGISwapChain3 * pDXGISwapChain3 = nullptr;
hr = pDXGISwapChain1->QueryInterface(IID_IDXGISwapChain3, (LPVOID*)&pDXGISwapChain3);
if (FAILED(hr)) return hr;
IDXGISwapChain3 * pDXGISwapChain3Copy = nullptr;
// Make a copy of the IDXGISwapChain3 interface pointer.
// Call AddRef to increment the reference count and to ensure that
// the object is not destroyed prematurely.
pDXGISwapChain3Copy = pDXGISwapChain3;
pDXGISwapChain3Copy->AddRef();
...
// Cleanup code. Check to see whether the pointers are still active.
// If they are, then call Release to release the interface.
if (pDXGISwapChain1 != nullptr)
{
pDXGISwapChain1->Release();
pDXGISwapChain1 = nullptr;
}
if (pDXGISwapChain3 != nullptr)
{
pDXGISwapChain3->Release();
pDXGISwapChain3 = nullptr;
}
if (pDXGISwapChain3Copy != nullptr)
{
pDXGISwapChain3Copy->Release();
pDXGISwapChain3Copy = nullptr;
}
COM 스마트 포인터
지금까지 코드는 IUnknown 메서드를 사용하여 참조 수를 유지하기 위해 및 AddRef 를 명시적으로 호출 Release 했습니다. 이 패턴을 사용하려면 프로그래머가 가능한 모든 코드 경로에서 개수를 제대로 유지하기 위해 열심히 기억해야 합니다. 이로 인해 복잡한 오류 처리가 발생할 수 있으며 C++ 예외 처리를 사용하도록 설정하면 구현하기가 특히 어려울 수 있습니다. C++를 사용하는 더 나은 솔루션은 스마트 포인터를 사용하는 것입니다.
winrt::com_ptrC++/WinRT 언어 프로젝션에서 제공하는 스마트 포인터입니다. UWP 앱에 사용할 권장 COM 스마트 포인터입니다. C++/WinRT에는 C++17이 필요합니다.
Microsoft::WRL::ComPtr은 Windows 런타임 C++ WRL(템플릿 라이브러리)에서 제공하는 스마트 포인터입니다. 이 라이브러리는 "순수" C++이므로 Windows 런타임 애플리케이션(C++/CX 또는 C++/WinRT를 통해)과 Win32 데스크톱 애플리케이션에 사용할 수 있습니다. 이 스마트 포인터는 Windows 런타임 API를 지원하지 않는 이전 버전의 Windows에서도 작동합니다. Win32 데스크톱 애플리케이션의 경우 를 사용하여
#include <wrl/client.h>이 클래스만 포함하고 선택적으로 전처리기 기호__WRL_CLASSIC_COM_STRICT__도 정의할 수 있습니다. 자세한 내용은 COM 스마트 포인터 다시 보기를 참조하세요.CComPtr 은 ATL(활성 템플릿 라이브러리)에서 제공하는 스마트 포인터입니다. Microsoft::WRL::ComPtr은 다양한 미묘한 사용 문제를 해결하는 이 구현의 최신 버전이므로 새 프로젝트에는 이 스마트 포인터를 사용하지 않는 것이 좋습니다. 자세한 내용은 CComPtr 및 CComQIPtr를 만들고 사용하는 방법을 참조하세요.
DirectX 9에서 ATL 사용
DirectX 9에서 ATL(활성 템플릿 라이브러리)을 사용하려면 ATL 호환성을 위해 인터페이스를 다시 정의해야 합니다. 이렇게 하면 CComQIPtr 클래스를 제대로 사용하여 인터페이스에 대한 포인터를 가져올 수 있습니다.
다음 오류 메시지가 표시되므로 ATL에 대한 인터페이스를 다시 정의하지 않는지 알 수 있습니다.
[...]\atlmfc\include\atlbase.h(4704) : error C2787: 'IDirectXFileData' : no GUID has been associated with this object
다음 코드 샘플에서는 IDirectXFileData 인터페이스를 정의하는 방법을 보여줍니다.
// Explicit declaration
struct __declspec(uuid("{3D82AB44-62DA-11CF-AB39-0020AF71E433}")) IDirectXFileData;
// Macro method
#define RT_IID(iid_, name_) struct __declspec(uuid(iid_)) name_
RT_IID("{1DD9E8DA-1C77-4D40-B0CF-98FEFDFF9512}", IDirectXFileData);
인터페이스를 재정의한 후 Attach 메서드를 사용하여 ::D irect3DCreate9에서 반환된 인터페이스 포인터에 인터페이스를 연결해야 합니다. 그렇지 않으면 스마트 포인터 클래스에서 IDirect3D9 인터페이스가 제대로 해제되지 않습니다.
CComPtr 클래스는 개체를 만들 때 및 인터페이스가 CComPtr 클래스에 할당될 때 인터페이스 포인터에서 IUnknown::AddRef를 내부적으로 호출합니다. 인터페이스 포인터가 누출되지 않도록 하려면 ::D irect3DCreate9에서 반환된 인터페이스에서 **IUnknown::AddRef를 호출하지 마세요.
다음 코드는 IUnknown::AddRef를 호출하지 않고 인터페이스를 제대로 해제합니다.
CComPtr<IDirect3D9> d3d;
d3d.Attach(::Direct3DCreate9(D3D_SDK_VERSION));
이전 코드를 사용합니다. IUnknown::AddRef 뒤에 IUnknown::Release를 호출하고 ::D irect3DCreate9에 의해 추가된 참조를 해제하지 않는 다음 코드를 사용하지 마세요.
CComPtr<IDirect3D9> d3d = ::Direct3DCreate9(D3D_SDK_VERSION);
이러한 방식으로 Attach 메서드를 사용해야 하는 Direct3D 9의 유일한 위치입니다.
CComPTR 및 CComQIPtr 클래스에 대한 자세한 내용은 헤더 파일에서 Atlbase.h 해당 정의를 참조하세요.
피드백
출시 예정: 2024년 내내 콘텐츠에 대한 피드백 메커니즘으로 GitHub 문제를 단계적으로 폐지하고 이를 새로운 피드백 시스템으로 바꿀 예정입니다. 자세한 내용은 다음을 참조하세요. https://aka.ms/ContentUserFeedback
다음에 대한 사용자 의견 제출 및 보기