Microsoft MVP성태의 닷넷 이야기
VC++: 155. CComPtr/CComQIPtr과 Conformance mode 옵션의 충돌 [링크 복사], [링크+제목 복사],
조회: 11080
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일
 
(연관된 글이 4개 있습니다.)

CComPtr/CComQIPtr과 Conformance mode 옵션의 충돌

별다른 생성자를 추가하지 않은 경우, 클래스의 형변환은 상위 클래스로는 가능해도 하위 클래스로는 불가능합니다. 간단하게 테스트를 해볼까요?

class MyType
{
public:
    int f = 100;

    MyType() { }
};

class MyDervied : public MyType
{
public:
    bool result = true;

    MyDervied() { f = 200; }
};

위와 같은 클래스 구조에서, 다음과 같이 코드를 사용하면,

MyDervied test;
MyType t = test;

printf("test = %d, t = %d\n", t.f, test.f); // t = 200, test = 200

정상적으로 컴파일 및 빌드가 됩니다. 하지만, 반대로 부모 인스턴스를 자식 인스턴스에 대입하려는 시도는,

MyType t;
MyDervied test = t; // Error C2440 'initializing': cannot convert from 'MyType' to 'MyDervied'

보는 바와 같이 오류가 발생합니다.




위의 코드를 개선해 볼까요? 우선 자식을 부모 클래스에 대입하는 경우는 비록 컴파일은 가능하지만 Visual Studio의 코드 편집기 상에서 "t = test" 코드에 밑줄이 표시되면서 "C26437: Do not slice (es.63)" 경고를 알려줍니다. 이 경고를 없애려면, 명시적으로 부모 타입에 생성자를 하나 추가해 주면 됩니다.

class MyType
{
public:
    int f = 100;

    MyType() { }

    MyType(MyType& inst)
    {
        this->f = inst.f;
    }
};

그리고, 부모 인스턴스를 자식 인스턴스에 대입하는 것도 역시 자식 인스턴스에서 부모 인스턴스를 받아들이는 생성자를 정의해 주면 됩니다.

class MyDervied : public MyType
{
public:
    bool result = true;

    MyDervied() { this->f = 200; }

    MyDervied(MyType& inst)
    {
        this->f = inst.f;
    }
};

MyType t;
MyDervied test = t; // 정상적으로 컴파일

일단, 여기까지는 다들 아시는 그대로입니다.




이 상황에서 template을 사용하면 어떻게 될까요?

template <class T>
class MyType
{
public:
    int f = 100;

    MyType() { }

    MyType(MyType& inst)
    {
       this->f = inst.f;
    }
};

template <class T>
class MyDervied : public MyType<T>
{
public:
    bool result = true;

    MyDervied() { this->f = 200; }

    MyDervied(MyType<T>& inst)
    {
        this->f = inst.f;
    }
};

일단, 위와 같은 경우 다음과 같은 식으로는 잘 컴파일이 됩니다.

{
    MyDervied<int> test;
    MyType<int> t = test;

    printf("t = %d, test = %d\n", t.f, test.f);
}

{
    MyType<int> t;
    MyDervied<int> test = t;

    printf("t = %d, test = %d\n", t.f, test.f);
}

하지만, 만약 템플릿 타입 인자가 다르다면 어떻게 될까요?

{
    MyDervied<int> test;
    MyType<long> t = test; // Error C2440 'initializing': cannot convert from 'MyDervied' to 'MyType'
}

이런 경우, 컴파일러는 타입이 다르기 때문에 당연히 오류가 발생합니다.




그런데, 저 템플릿 타입이 달라도 컴파일이 되고 싶은 경우가 있습니다. 다소 특수한 사례를 들어서, 템플릿 인자 간의 상속 관계가 있는 경우 형변환을 허용하고 싶다면 다음과 같은 식으로 코딩을 할 수 있습니다.

class Root { };

class Node : public Root { };

class Terminal : public Root { };

template <class T>
class MyType
{
public:
    MyType() { }

    operator T& () { return p; }

    T p;
};

template <class T>
class MyDerived : public MyType<T>
{
public:
    MyDerived() { }

    MyDerived(Root& inst)
    {
    }
};

위의 코드는 이렇게 사용하는 것이 가능합니다. (자식 타입으로 형변환하고 있습니다.)

{
    MyType<Terminal> t;
    MyDerived<Node> test = t;
}

잘 보시면, t 인스턴스는 MyType의 T&() 연산자로 인해 Terminal 타입에 해당하는 인스턴스를 반환합니다. 그리고 MyDerived의 생성자는 Root& 타입을 인자로 정의했으므로 Terminal 타입의 인스턴스를 받을 수 있습니다.

여기서 재미있는 것은, 저 코드가 Visual C++의 "Conformance mode"를 적용하는 경우에는 컴파일 오류가 발생한다는 점입니다. 실제로 프로젝트 속성 창에서 "Configuration Properties" / "C/C++" / "Language" 범주로 들어가 "Conformance mode" 옵션을 "Yes (/permissive-)"로 켜면,

atl_cpp_conformance_mode_0.png

이후 "test = t;" 코드에서 다음과 같은 컴파일 오류가 발생합니다.

Error C2440 'initializing': cannot convert from 'MyType<Terminal>' to 'MyDerived<Node>'

즉, 무조건 템플릿 타입 인자가 같아야 한다는 것을 강제하는 것입니다. 하지만 템플릿 타입을 같게 만들어도 여전히 컴파일 오류가 발생합니다.

{
    MyType<Terminal> t;
    MyDerived<Terminal> test = t; // Error C2440 'initializing': cannot convert from 'MyType<T>' to 'MyDerived<Terminal>'
}

왜냐하면, 부모 클래스의 인스턴스를 자식 클래스의 인스턴스로 대입하려 했기 때문입니다. 따라서 다시 원론적으로 돌아와서, 상속받은 타입에서 부모 클래스의 인스턴스로 형변환하는 것만을 허용하게 된 것입니다.

{
    MyDerived<Terminal> test;
    MyType<Terminal> t = test;
}

즉, 이것은 템플릿을 사용하지 않던 원래의 클래스 타입과 동일한 규칙이 적용되는 것이어서 이제는 별다른 생성자도 필요하지 않습니다. 따라서, 위와 같은 코드는 그냥 다음과 같이 기본 클래스를 정의해도 가능한 수준입니다.

template <class T>
class MyType
{
public:
    MyType() { }
};

template <class T>
class MyDerived : public MyType<T>
{
public:
    MyDerived() { }
};




아니... 그나저나 도대체 저런 이상한 형태의 클래스 상속을 누가 사용한단 말입니까? ^^; 자, 서론이 길었군요. 바로 저런 식으로 사용하는 사례가 CComPtr과 CComQIPtr입니다.

이 타입들을 축약하면 다음과 같이 정의할 수 있습니다.

#include <d3d11.h>
#include <Unknwnbase.h>

template <class T>
class CComPtr
{
public:
    CComPtr() { p = nullptr; }

    CComPtr(T* lp) { p = lp; }

    operator T* () { return p; }

    T* p;
};

template <class T>
class CComQIPtr : public CComPtr<T>
{
public:
    CComQIPtr() { }

    CComQIPtr(IUnknown* lp) { }
};

보시면, CComQIPtr 생성자에서 IUnknown* 인자를 받아들이고, CComPtr에서는 T*() 연산자 오버로드로 포인터를 반환하고 있습니다. 즉, IUnknown을 상속한 타입을 템플릿 인자로 지정한 CComPtr 인스턴스는 CComQIPtr에 이렇게 대입하는 것이 가능합니다.

// IDXGIResource와 ID3D11Texture2D는 서로 다른 타입이지만, IUnknown을 상속
{
    CComPtr<IDXGIResource> pUnk;
    CComQIPtr<ID3D11Texture2D> pDisp = pUnk;
}

어차피 내부에서 IUnknown의 QueryInterface 함수를 호출하기 때문에 저렇게 사용하는 것은 어떠한 버그도 발생시키지 않습니다. 하지만, 저 코드 역시 마찬가지로 "Conformance mode"를 켜면 이렇게 오류가 발생합니다.

Error C2440 'initializing': cannot convert from 'CComPtr<IDXGIResource>' to 'CComQIPtr<ID3D11Texture2D>'




이 상황을 해결하려면 간단하게는 "Conformance" 모드를 끄면 됩니다. 하지만, 근래의 C++ 표준 준수를 위한 분위기를 고려한다면 좋은 선택이 아닙니다.

그렇다면, 다시 원론적으로 문제를 해결하는 수밖에는 없습니다. 일단, 대입은 안 되므로 다음과 같은 식으로 QueryInterface를 풀어쓰면서 스마트 포인터는 나름대로 그와 연동해 사용하는 것입니다.

// 이 한 줄의 코드를,
// CComQIPtr<ID3D11Texture2D> spTextureResource = spDXGIResource;
    
// 이렇게 풀어서 적용
CComQIPtr<ID3D11Texture2D> spTextureResource;
{
    ID3D11Texture2D* pTextureResource;
    hr = spDXGIResource->QueryInterface(__uuidof(ID3D11Texture2D), (LPVOID*)&pTextureResource);
    if (hr == S_OK)
    {
        spTextureResource.Attach(pTextureResource);
    }
}

좀 멋은 없어졌지만... 뭐 그래도... ^^;




그나저나, 갑자기 저 문제가 왜 발생한 것일까요? ^^ 문서를 보면 이에 대한 설명이 나옵니다.

/permissive- (Standards conformance)
; https://learn.microsoft.com/en-us/cpp/build/reference/permissive-standards-conformance

이 기능은 Visual Studio 2017부터 15.5 버전 이후로 기본값으로 바뀌었다고 합니다. 그러니까, "DXGI를 이용한 윈도우 화면 캡처 소스 코드(Visual C++)" 글을 썼던 게 2017-12-05일이니까 아마도 그때 당시에는 /permissive+ 상태가 기본값이어서 아무런 문제가 없었던 것입니다.

하지만, 15.5 버전 패치가 적용된 이후부터는 새 프로젝트를 만들어 저 소스코드를 복사해 적용한 사용자들의 경우에는 /permissive- 옵션의 영향으로 컴파일 오류가 발생했던 것입니다.

참고로, /permissive- 옵션은 C++ 표준 옵션을 "Preview - Features from the Latest C++ Working Draft (/std:c++latest)" 또는 "/std:c++20"으로 설정하면 암시적으로 켜진다고 합니다.




그런데, 생각보다 커뮤니티의 분위기가 조용합니다. 관련해서 검색해 보면 아래의 이슈 하나가 나오는데요,

afxhtml.h fails to compile when disabling permissive mode
; https://developercommunity.visualstudio.com/t/afxhtmlh-fails-to-compile-when-disabling-permissiv/471981

재현 예제 코드를 정리하면 결국 이것과 같습니다.

#include <atlbase.h>

int main()
{
    CComPtr<IUnknown> pUnk;
    CComQIPtr<IDispatch> pDisp = pUnk;
}

// After importing a TLB, how do I convert from one type of _com_ptr_t to another?
// https://devblogs.microsoft.com/oldnewthing/20221228-00/?p=107621

이슈 대응을 보면 "Visual Studio 2019 버전 16.3"부터 해결되었다고 나옵니다. 이상하군요, 전혀 해결되지 않았는데... 혹시 제가 모르는 또 다른 옵션이 있을까요? ^^ 암튼, 근래에는 아무래도 ATL COM의 분위기가 많이 식었기 때문에 그에 따라 CComPtr과 CComQIPtr을 사용하는 경우도 많지 않은 듯합니다.




참고로, 예전에 Conformance 모드 관련해 써 놓은 글이 하나 있군요. ^^

C++의 연산자 동의어(operator synonyms), 대체 토큰
; https://www.sysnet.pe.kr/2/0/12424




[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]

[연관 글]






[최초 등록일: ]
[최종 수정일: 3/15/2023]

Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.
by SeongTae Jeong, mailto:techsharer at outlook.com

비밀번호

댓글 작성자
 



2023-04-03 11시45분
What is this [uuid(…)] in front of my C++ class declaration?
; https://devblogs.microsoft.com/oldnewthing/20230331-00/?p=107998

permissive 옵션을 켜면, Visual C++의 비표준 확장을 사용할 수 없으므로 [uuid] 속성도 컴파일 오류가 발생한다고 합니다. 대신 __declspec을 사용하면 되는데, 이것 역시 비표준이지만 단지 표준 방식(2개의 밑줄로 시작하는 식별자)으로 확장된 것이므로 허용을 한다고.

What are the duck-typing requirements of _com_ptr_t?
; https://devblogs.microsoft.com/oldnewthing/20230508-00/?p=108156

-------------------------

"/std:c++20" 옵션인 경우 permissive 옵션을 명시적으로 끈다고 해도 여전히 permissive 옵션이 적용된다고 합니다.

In my Visual Studio project, I set my Conformance mode to permissive, but it’s still not permissive
; https://devblogs.microsoft.com/oldnewthing/20240725-00/?p=110045

이건 옵션의 적용 순서에 따른 버그로 보인다고 하는데요, 따라서 permissive 옵션을 설정 창을 통해 끄지 말고 그냥 "Additional Options"에 명시하는 식으로 우회할 수 있다고 합니다.

-------------------------

Extending CComPtr for remote activation
; https://www.codeproject.com/Articles/5386186/Extending-CComPtr-for-remote-activation
정성태

[1]  2  3  4  5  6  7  8  9  10  11  12  13  14  15  ...
NoWriterDateCnt.TitleFile(s)
13758정성태10/8/2024231오류 유형: 926. dotnet tools를 sudo로 실행하는 경우 command not found
13757정성태10/8/2024228닷넷: 2306. Linux - dotnet tool의 설치 디렉터리가 PATH 환경변수에 자동 등록이 되는 이유
13756정성태10/8/2024256오류 유형: 925. ssh로 docker 접근을 할 때 "... malformed HTTP status code ..." 오류 발생
13755정성태10/7/2024457닷넷: 2305. C# 13 - (9) 메서드 바인딩의 우선순위를 지정하는 OverloadResolutionPriority 특성 도입 (Overload resolution priority)파일 다운로드1
13754정성태10/4/2024395닷넷: 2304. C# 13 - (8) 부분 메서드 정의를 속성 및 인덱서에도 확대파일 다운로드1
13753정성태10/4/2024432Linux: 81. Linux - PATH 환경변수의 적용 규칙
13752정성태10/2/2024641닷넷: 2303. C# 13 - (7) ref struct의 interface 상속 및 제네릭 제약으로 사용 가능파일 다운로드1
13751정성태10/2/2024713C/C++: 176. C/C++ - ARM64로 포팅할 때 유의할 점
13750정성태10/1/2024766C/C++: 175. C++ - WinMain/wWinMain 호출 전의 CRT 초기화 단계
13749정성태9/30/2024880닷넷: 2302. C# - ssh-keygen으로 생성한 Private Key와 Public Key 연동파일 다운로드1
13748정성태9/29/2024971닷넷: 2301. C# - BigInteger 타입이 byte 배열로 직렬화하는 방식
13747정성태9/28/2024908닷넷: 2300. C# - OpenSSH의 공개키 파일에 대한 "BEGIN OPENSSH PUBLIC KEY" / "END OPENSSH PUBLIC KEY" PEM 포맷파일 다운로드1
13746정성태9/28/2024880오류 유형: 924. Python - LocalProtocolError("Illegal header value ...")
13745정성태9/28/2024889Linux: 80. 리눅스 - 실행 중인 프로세스 내부의 환경변수 설정을 구하는 방법 (lldb)
13744정성태9/27/20241029닷넷: 2299. C# - Windows Hello 사용자 인증 다이얼로그 표시하기파일 다운로드1
13743정성태9/26/20241288닷넷: 2298. C# - Console 프로젝트에서의 await 대상으로 Main 스레드 활용하는 방법 [1]
13742정성태9/26/20241000닷넷: 2297. C# - ssh-keygen으로 생성한 ecdsa 유형의 Public Key 파일 해석 [1]파일 다운로드1
13741정성태9/25/2024873디버깅 기술: 202. windbg - ASP.NET MVC Web Application (.NET Framework) 응용 프로그램의 덤프 분석 시 요령
13740정성태9/24/2024971기타: 86. RSA 공개키 등의 modulus 값에 0x00 선행 바이트가 있는 이유(ASN.1 인코딩)
13739정성태9/24/20241042닷넷: 2297. C# - ssh-keygen으로 생성한 Public Key 파일 해석과 fingerprint 값(md5, sha256) 생성파일 다운로드1
13738정성태9/22/2024979C/C++: 174. C/C++ - 윈도우 운영체제에서의 file descriptor, FILE*파일 다운로드1
13737정성태9/21/20241096개발 환경 구성: 727. Visual C++ - 리눅스 프로젝트를 위한 빌드 서버의 msbuild 구성
13736정성태9/20/20241231오류 유형: 923. Visual Studio Code - Could not establish connection to "...": Port forwarding is disabled.
13735정성태9/20/20241312개발 환경 구성: 726. ARM 플랫폼용 Visual C++ 리눅스 프로젝트 빌드
13734정성태9/19/20241350개발 환경 구성: 725. ssh를 이용한 원격 docker 서비스 사용
[1]  2  3  4  5  6  7  8  9  10  11  12  13  14  15  ...