C++/WinRT에 대해 자주 묻는 질문Frequently-asked questions about C++/WinRT

C++/WinRT를 통해 Windows 런타임 API를 작성하거나 사용하는 방법과 관련된 질문과 대답입니다.Answers to questions that you're likely to have about authoring and consuming Windows Runtime APIs with C++/WinRT.

참고

표시된 오류 메시지에 대한 질문이 있는 경우 C++/WinRT 문제 해결 항목도 참조하세요.If your question is about an error message that you've seen, then also see the Troubleshooting C++/WinRT topic.

C++/WinRT 프로젝트의 대상을 Windows SDK 최신 버전으로 변경하려면 어떻게 하나요?How do I retarget my C++/WinRT project to a later version of the Windows SDK?

C++/WinRT 프로젝트의 대상을 Windows SDK 최신 버전으로 변경하는 방법을 참조하세요.See How to retarget your C++/WinRT project to a later version of the Windows SDK.

이제 C++/WinRT 2.0으로 이동했는데도 새 프로젝트가 컴파일되지 않는 이유는 무엇인가요?Why won't my new project compile, now that I've moved to C++/WinRT 2.0?

호환성이 손상되는 변경 내용을 비롯한 전체 변경 내용 세트는 C++/WinRT 2.0의 뉴스 및 변경 내용을 참조하세요.For the full set of changes (including breaking changes), see News, and changes, in C++/WinRT 2.0. 예를 들어 Windows 런타임 컬렉션에서 범위 기반의 for를 사용하는 경우 이제 #include <winrt/Windows.Foundation.Collections.h>가 필요합니다.For example, if you're using a range-based for on a Windows Runtime collection, then you'll now need to #include <winrt/Windows.Foundation.Collections.h>.

새 프로젝트가 컴파일되지 않는 이유는 무엇인가요?Why won't my new project compile? Visual Studio 2017(버전 15.8.0 이상) 및 SDK 버전 17134를 사용하고 있습니다.I'm using Visual Studio 2017 (version 15.8.0 or higher), and SDK version 17134

Visual Studio 2017(버전 15.8.0 이상)을 사용 중이고 Windows SDK 버전 10.0.17134.0(Windows 10 버전, 1803)을 대상으로 하는 경우, 새로 만든 C++/WinRT 프로젝트가 컴파일되지 않고 “오류 C3861: ‘from_abi’: 식별자를 찾을 수 없음” 오류와 base.h에서 발생하는 기타 오류가 표시될 수 있습니다. If you're using Visual Studio 2017 (version 15.8.0 or higher), and targeting the Windows SDK version 10.0.17134.0 (Windows 10, version 1803), then a newly created C++/WinRT project may fail to compile with the error "error C3861: 'from_abi': identifier not found", and with other errors originating in base.h. 해결 방법으로, 보다 규칙에 맞는 Windows SDK 최신 버전을 대상으로 지정하거나, 프로젝트 속성 C/C++ > 언어 > 적합성 모드: 아니요를 설정합니다. 또는 추가 옵션 아래의 프로젝트 속성 C/C++ > 명령줄/permissive- 가 표시되는 경우 삭제합니다.The solution is to either target a later (more conformant) version of the Windows SDK, or set project property C/C++ > Language > Conformance mode: No (also, if /permissive- appears in project property C/C++ > Command Line under Additional Options, then delete it).

빌드 오류 “C++/WinRT VSIX에서 더 이상 프로젝트 빌드 지원을 제공하지 않습니다.How do I resolve the build error "The C++/WinRT VSIX no longer provides project build support. Microsoft.Windows.CppWinRT Nuget 패키지에 프로젝트 참조를 추가하세요.”를 해결하려면 어떻게 하나요?Please add a project reference to the Microsoft.Windows.CppWinRT Nuget package"?

Microsoft.Windows.CppWinRT NuGet 패키지를 프로젝트에 설치합니다.Install the Microsoft.Windows.CppWinRT NuGet package into your project. 자세한 내용은 이전 버전의 VSIX 확장을 참조하세요.For details, see Earlier versions of the VSIX extension.

NuGet 패키지에서 빌드 지원을 사용자 지정하려면 어떻게 할까요??How do I customize the build support in the NuGet package?

C++/WinRT 빌드 지원(속성/대상)은 Microsoft.Windows.CppWinRT NuGet 패키지 readme에 문서화되어 있습니다.C++/WinRT build support (props/targets) is documented in the Microsoft.Windows.CppWinRT NuGet package readme.

C++/WinRT VSIX(Visual Studio Extension)의 요구 사항은 무엇인가요?What are the requirements for the C++/WinRT Visual Studio Extension (VSIX)?

VSIX 확장 버전 1.0.190128.4 이상의 경우 Visual Studio의 C++/WinRT 지원을 참조하세요.For version 1.0.190128.4 of the VSIX extension and later, see Visual Studio support for C++/WinRT. 다른 버전의 경우 이전 버전의 VSIX 확장을 참조하세요.For other versions, see Earlier versions of the VSIX extension.

런타임 클래스란 무엇인가요?What's a runtime class?

런타임 클래스는 일반적으로 실행 가능한 경계를 넘어서 최신 COM 인터페이스를 통해 활성화 및 사용할 수 있는 형식입니다.A runtime class is a type that can be activated and consumed via modern COM interfaces, typically across executable boundaries. 하지만 런타임 클래스를 구현하는 컴파일 단위 내에서 사용할 수도 있습니다.However, a runtime class can also be used within the compilation unit that implements it. 런타임 클래스는 IDL(Interface Definition Language)로 선언하며, C++/WinRT를 사용하여 표준 C++로 구현할 수 있습니다.You declare a runtime class in Interface Definition Language (IDL), and you can implement it in standard C++ using C++/WinRT.

‘프로젝션된 형식’과 ‘구현 형식’은 무엇을 의미하나요? What do the projected type and the implementation type mean?

Windows 런타임 클래스(런타임 클래스)를 ‘사용’하기만 하는 경우에는 ‘프로젝션된 형식’만 처리하게 됩니다. If you're only consuming a Windows Runtime class (runtime class), then you'll be dealing exclusively with projected types. C++/WinRT는 ‘언어 프로젝션’이므로, 프로젝션된 형식이란 C++/WinRT를 사용하여 C++로 ‘프로젝션된’ Windows 런타임의 표면 중 일부를 말합니다. C++/WinRT is a language projection, so projected types are part of the surface of the Windows Runtime that's projected into C++ with C++/WinRT. 자세한 내용은 C++/WinRT를 통한 API 사용을 참조하세요.For more details, see Consume APIs with C++/WinRT.

‘구현 형식’에는 런타임 클래스 구현이 포함되므로, 런타임 클래스를 구현하는 프로젝트에서만 사용할 수 있습니다. The implementation type contains the implementation of a runtime class, so it's only available in the project that implements the runtime class. 런타임 클래스를 구현하는 프로젝트(Windows 런타임 구성 요소 프로젝트 또는 XAML UI를 사용하는 프로젝트)에서 작업 중인 경우 런타임 클래스의 구현 형식과 C++/WinRT에 프로젝션된 런타임 클래스를 나타내는 프로젝션된 형식 간의 차이점을 잘 아는 것이 중요합니다.When you're working in a project that implements runtime classes (a Windows Runtime component project, or a project that uses XAML UI), it's important to be comfortable with the distinction between your implementation type for a runtime class, and the projected type that represents the runtime class projected into C++/WinRT. 자세한 내용은 C++/WinRT를 통한 API 작성을 참조하세요.For more details, see Author APIs with C++/WinRT.

런타임 클래스의 IDL로 생성자를 선언해야 하나요?Do I need to declare a constructor in my runtime class's IDL?

런타임 클래스가 구현하는 컴파일 단위의 외부에서 사용하도록 설계된 경우에 한합니다(여기에서 런타임 클래스는 Windows 런타임 클라이언트 앱에서 일반 용도로 사용하는 Windows 런타임 구성 요소임).Only if the runtime class is designed to be consumed from outside its implementing compilation unit (it's a Windows Runtime component intended for general consumption by Windows Runtime client apps). 생성자를 IDL로 선언하는 목적과 결과에 대한 자세한 내용은 런타임 클래스 생성자를 참조하세요.For full details on the purpose and consequences of declaring constructor(s) in IDL, see Runtime class constructors.

링커에서 “LNK2019: 확인되지 않은 외부 기호” 오류가 발생하는 이유는 무엇인가요?Why is the linker giving me a "LNK2019: Unresolved external symbol" error?

확인되지 않은 기호가 winrt 네임스페이스에 있는 C++/WinRT 프로젝션의 Windows 네임스페이스 헤더 API인 경우 API는 포함한 헤더에서 정방향으로 선언되지만 해당 정의는 아직 포함하지 않은 헤더에 있습니다.If the unresolved symbol is an API from the Windows namespace headers for the C++/WinRT projection (in the winrt namespace), then the API is forward-declared in a header that you've included, but its definition is in a header that you haven't yet included. API 네임스페이스를 따라 명명된 헤더를 추가하고 다시 빌드합니다.Include the header named for the API's namespace, and rebuild. 자세한 내용은 C++/WinRT 프로젝션 헤더를 참조하세요.For more info, see C++/WinRT projection headers.

확인되지 않은 기호가 RoInitialize와 같은 Windows 런타임 프리 함수인 경우 프로젝트에서 WindowsApp.lib 상위 라이브러리를 명시적으로 연결해야 합니다.If the unresolved symbol is a Windows Runtime free function, such as RoInitialize, then you'll need to explicitly link the WindowsApp.lib umbrella library in your project. C++/WinRT 프로젝션은 이러한 프리(비멤버) 함수 및 진입점에 따라 달라집니다.The C++/WinRT projection depends on some of these free (non-member) functions and entry points. 애플리케이션에 C++/WinRT VSIX(Visual Studio Extension) 프로젝트 템플릿 중 하나를 사용하는 경우 WindowsApp.lib가 자동으로 연결됩니다.If you use one of the C++/WinRT Visual Studio Extension (VSIX) project templates for your application, then WindowsApp.lib is linked for you automatically. 그러지 않으면 프로젝트 연결 설정을 사용하여 포함하거나, 소스 코드에서 포함할 수 있습니다.Otherwise, you can use project link settings to include it, or do it in source code.

#pragma comment(lib, "windowsapp")

대체 정적 연결 라이브러리 대신 WindowsApp.lib를 연결하여 해결할 수 있는 링커 오류를 모두 해결하는 것이 중요합니다. 그러지 않으면 애플리케이션이 Visual Studio 및 Microsoft Store에서 제출의 유효성 검사에 사용하는 Windows 앱 인증 키트 테스트를 통과하지 못하기 때문에 애플리케이션을 Microsoft Store로 수집할 수 없습니다.It's important that you resolve any linker errors that you can by linking WindowsApp.lib instead of an alternative static-link library, otherwise your application won't pass the Windows App Certification Kit tests used by Visual Studio and by the Microsoft Store to validate submissions (meaning that it consequently won't be possible for your application to be successfully ingested into the Microsoft Store).

"클래스가 등록되지 않음" 예외가 발생하는 이유는 무엇인가요?Why am I getting a "class not registered" exception?

이런 경우 해당 증상은 (런타임 클래스를 생성하거나 정적 멤버에 액세스할 때) REGDB_E_CLASSNOTREGISTERED의 HRESULT 값을 사용하여 런타임에서 예외가 발생한 것입니다.In this case, the symptom is that—when constructing a runtime class or accessing a static member—you see an exception thrown at runtime with a HRESULT value of REGDB_E_CLASSNOTREGISTERED.

한 가지 원인은 Windows 런타임 구성 요소를 로드할 수 없기 때문일 수 있습니다.One cause can be that your Windows Runtime component can't be loaded. 구성 요소의 Windows 런타임 메타데이터 파일(.winmd) 이름이 구성 요소 이진(.dll) 이름과 같은지 확인합니다. 프로젝트 이름이자 루트 네임스페이스 이름이기도 합니다.Make sure that the component's Windows Runtime metadata file (.winmd) has the same name as the component binary (the .dll), which is also the name of the project and the name of the root namespace. Windows 런타임 메타데이터와 이진이 빌드 프로세스를 통해 사용하는 앱의 Appx 폴더로 정확히 복사되었는지도 확인합니다.Also make sure that the Windows Runtime metadata and the binary have been corectly copied by the build process to the consuming app's Appx folder. 또한 사용하는 앱의 AppxManifest.xml(Appx 폴더에 있음)에 활성화 가능한 클래스와 이진 이름을 올바르게 선언하는 <InProcessServer> 요소가 포함되어 있는지 확인합니다.And confirm that the consuming app's AppxManifest.xml (also in the Appx folder) contains an <InProcessServer> element correctly declaring the activatable class and the binary name.

균일한 생성Uniform construction

프로젝션된 형식의 생성자 중 하나(std::nullptr_t 생성자 제외)를 통해 로컬로 구현한 런타임 클래스를 인스턴스화하려는 경우에도 이 오류가 발생할 수 있습니다.This error can also happen if you try to instantiate a locally-implemented runtime class via any of the projected type's constructors (other than its std::nullptr_t constructor). 이 작업을 수행하려면 균일한 생성이라고 부르는 C++/WinRT 2.0 기능이 필요합니다.To do that, you'll need the C++/WinRT 2.0 feature that's often called uniform construction. 해당 기능을 옵트인하려고 하고 자세한 내용과 코드 예제를 알아보려면 균일한 생성 및 직접 구현 액세스 옵트인을 참조하세요.If you want to opt in to that feature, then for more info, and code examples, see Opt in to uniform construction, and direct implementation access.

균일한 생성이 필요하지 않은 로컬로 구현한 런타임 클래스를 인스턴스화하는 방법은 XAML 컨트롤, C++/WinRT 속성에 바인딩을 참조하세요.For a way of instantiating your locally-implemented runtime classes that doesn't require uniform construction, see XAML controls; bind to a C++/WinRT property.

Windows::Foundation::IClosable을 구현해야 하나요? 구현해야 한다면 어떻게 구현하나요?Should I implement Windows::Foundation::IClosable and, if so, how?

소멸자에서 리소스를 해제하는 런타임 클래스가 있고, 이 런타임 클래스가 구현하는 컴파일 단위 외부에서 사용하도록 설계된 경우(여기에서 런타임 클래스는 Windows 런타임 클라이언트 앱에서 일반 용도로 사용하는 Windows 런타임 구성 요소임), 결정적 종료가 없는 언어에서 런타임 클래스를 사용할 수 있도록 지원하기 위해 IClosable도 구현하는 것이 좋습니다.If you have a runtime class that frees resources in its destructor, and that runtime class is designed to be consumed from outside its implementing compilation unit (it's a Windows Runtime component intended for general consumption by Windows Runtime client apps), then we recommend that you also implement IClosable in order to support the consumption of your runtime class by languages that lack deterministic finalization. 소멸자, IClosable::Close 또는 둘 다 호출하든 관계없이 리소스가 해제되는지 확인합니다.Make sure that your resources are freed whether the destructor, IClosable::Close, or both are called. IClosable::Close는 원하는 횟수만큼 임의로 호출할 수 있습니다.IClosable::Close may be called an arbitrary number of times.

사용하는 런타임 클래스에서 IClosable::Close를 호출해야 하나요?Do I need to call IClosable::Close on runtime classes that I consume?

IClosable은 결정적 종료가 없는 언어를 지원하기 위한 것입니다.IClosable exists to support languages that lack deterministic finalization. 따라서 C++/WinRT에서는 IClosable::Close를 호출하지 않아도 됩니다. 단, 매우 드물지만 종료 경합 또는 반 교착 상태와 관련된 경우는 예외입니다.So, you shouldn't call IClosable::Close from C++/WinRT, except in very rare cases involving shutdown races or semi-deadly embraces. 예를 들어 Windows.UI.Composition 형식을 사용한다면, C++/WinRT 래퍼의 소멸을 통해 개체를 삭제하는 대신 설정된 시퀀스에서 개체를 삭제하려는 경우가 발생할 수 있습니다.If you're using Windows.UI.Composition types, as an example, then you may encounter cases where you want to dispose objects in a set sequence, as an alternative to allowing the destruction of the C++/WinRT wrapper do the work for you.

C++/WinRT로 컴파일하기 위해 LLVM/Clang을 사용할 수 있나요?Can I use LLVM/Clang to compile with C++/WinRT?

LLVM 및 Clang 도구 체인은 C++/WinRT에서 지원되지 않지만 C++/WinRT의 표준 적합성의 유효성을 검사하기 위해 내부적으로 사용됩니다.We don't support the LLVM and Clang toolchain for C++/WinRT, but we do make use of it internally to validate C++/WinRT's standards conformance. 예를 들어 Microsoft가 내부적으로 수행하는 작업을 에뮬레이트하려는 경우 아래에 설명된 대로 실험해 볼 수 있습니다.For example, if you wanted to emulate what we do internally, then you could try an experiment such as the one described below.

LLVM Download Page(LLVM 다운로드 페이지)로 이동하여 Download LLVM 6.0.0(LLVM 6.0.0 다운로드) > Pre-Built Binaries(미리 빌드된 이진)를 찾은 다음, Clang for Windows (64-bit) (Windows용 Clang(64비트))를 다운로드합니다.Go to the LLVM Download Page, look for Download LLVM 6.0.0 > Pre-Built Binaries, and download Clang for Windows (64-bit). 설치 중에 명령 프롬프트에서 호출할 수 있도록 LLVM을 PATH 시스템 변수에 추가할 수 있습니다.During installation, opt to add LLVM to the PATH system variable so that you'll be able to invoke it from a command prompt. 이 실험의 목적을 위해 “MSBuild 도구 세트 디렉터리를 찾지 못했습니다.” 또는 “MSVC 통합을 설치하지 못했습니다.” 오류가 표시되는 경우 모두 무시해도 됩니다.For the purposes of this experiment, you can ignore any "Failed to find MSBuild toolsets directory" and/or "MSVC integration install failed" errors, if you see them. LLVM/Clang을 호출하는 방법은 여러 가지가 있습니다. 아래 예제는 이러한 방법 중 하나일 뿐입니다.There are a variety of ways to invoke LLVM/Clang; the example below shows just one way.

C:\ExperimentWithLLVMClang>type main.cpp
// main.cpp
#pragma comment(lib, "windowsapp")
#pragma comment(lib, "ole32")

#include <winrt/Windows.Foundation.h>
#include <stdio.h>
#include <iostream>

using namespace winrt;

int main()
{
    winrt::init_apartment();
    Windows::Foundation::Uri rssFeedUri{ L"https://blogs.windows.com/feed" };
    std::wcout << rssFeedUri.Domain().c_str() << std::endl;
}

C:\ExperimentWithLLVMClang>clang-cl main.cpp /EHsc /I ..\.. -Xclang -std=c++17 -Xclang -Wno-delete-non-virtual-dtor -o app.exe

C:\ExperimentWithLLVMClang>app
windows.com

C++/WinRT는 C++17 표준의 기능을 사용하기 때문에 해당 지원을 얻는 데 필요한 컴파일러 플래그를 모두 사용해야 합니다. 이러한 플래그는 컴파일러마다 다릅니다.Because C++/WinRT uses features from the C++17 standard, you'll need to use whatever compiler flags are necessary to get that support; such flags differ from one compiler to another.

Visual Studio는 C++/WinRT용으로 지원 및 추천되는 개발 도구입니다.Visual Studio is the development tool that we support and recommend for C++/WinRT. Visual Studio의 C++/WinRT 지원을 참조하세요.See Visual Studio support for C++/WinRT.

읽기 전용 속성에 대해 생성된 구현 함수에 const 한정자가 없는 이유는 무엇인가요?Why doesn't the generated implementation function for a read-only property have the const qualifier?

MIDL 3.0에서 읽기 전용 속성을 선언하는 경우 cppwinrt.exe 도구에서 const로 한정된 구현 함수를 생성할 것을 예상할 수 있습니다(const 함수는 this 포인터를 const로 처리함).When you declare a read-only property in MIDL 3.0, you might expect the cppwinrt.exe tool to generate an implementation function for you that is const-qualified (a const function treats the this pointer as const).

가능한 경우 항상 const를 사용하는 것이 좋지만, cppwinrt.exe 도구 자체는 const가 될 수 있는 구현 함수와 const가 될 수 없는 구현 함수를 추론하지 않습니다.We certainly recommend using const wherever possible, but the cppwinrt.exe tool itself doesn't attempt to reason about which implementation functions might conceivably be const, and which might not. 이 예제와 같이 모든 구현 함수를 const를 설정할 수 있습니다.You can choose to make any of your implementation functions const, as in this example.

struct MyStringable : winrt::implements<MyStringable, winrt::Windows::Foundation::IStringable>
{
    winrt::hstring ToString() const
    {
        return L"MyStringable";
    }
};

구현에서 일부 개체 상태를 변경해야 하는 경우 ToStringconst 한정자를 제거할 수 있습니다.You can remove that const qualifier on ToString should you decide that you need to alter some object state in its implementation. 그러나 각 멤버 함수를 const 또는 비const로 설정해야 하며, 둘 다로 설정하면 안 됩니다.But make each of your member functions either const or non-const, not both. 즉, const에 구현 함수를 오버로드하지 않습니다.In other words, don't overload an implementation function on const.

구현 함수 외에도 const는 Windows 런타임 함수 프로젝션에서 중요합니다.Aside from your implementation functions, another other place where const comes into the picture is in Windows Runtime function projections. 다음 코드를 살펴보세요.Consider this code.

int main()
{
    winrt::Windows::Foundation::IStringable s{ winrt::make<MyStringable>() };
    auto result{ s.ToString() };
}

위의 ToString 호출에서 Visual Studio의 선언으로 이동 명령을 실행하면 Windows 런타임 IStringable::ToString을 C++/WinRT로 프로젝션하는 작업이 다음과 같이 표시됩니다.For the call to ToString above, the Go To Declaration command in Visual Studio shows that the projection of the Windows Runtime IStringable::ToString into C++/WinRT looks like this.

winrt::hstring ToString() const;

프로젝션의 함수는 선택한 구현 한정 방법에 관계없이 const입니다.Functions on the projection are const no matter how you choose to qualify your implementation of them. 백그라운드에서 프로젝션은 COM 인터페이스 포인터를 통한 호출인 ABI(애플리케이션 이진 인터페이스) 호출을 수행합니다.Behind the scenes, the projection calls the application binary interface (ABI), which amounts to a call through a COM interface pointer. 프로젝션된 ToString이 상호 작용하는 상태는 COM 인터페이스 포인터뿐이고 해당 포인터를 수정할 필요가 없으므로 함수는 const입니다.The only state that the projected ToString interacts with is that COM interface pointer; and it certainly has no need to modify that pointer, so the function is const. 따라서 호출 시 사용하는 IStringable 참조가 변경되지 않으며, IStringable에 대한 const 참조를 통해서도 ToString을 호출할 수 있습니다.This gives you the assurance that it won't change anything about the IStringable reference that you're calling through, and it ensures that you can call ToString even with a const reference to an IStringable.

이러한 const 예제는 C++/WinRT 프로젝션 및 구현의 구현 정보이며, 사용자에게 유용한 코드 예방 조치입니다.Understand that these examples of const are implementation details of C++/WinRT projections and implementations; they constitute code hygiene for your benefit. COM 또는 Windows 런타임 ABI(멤버 함수의 경우)에는 const에 해당하는 요소가 없습니다.There's no such thing as const on the COM nor Windows Runtime ABI (for member functions).

C++/WinRT 이진의 코드 크기를 줄이는 방법에 대한 권장 사항이 있나요?Do you have any recommendations for decreasing the code size for C++/WinRT binaries?

Windows 런타임 개체로 작업하는 경우 아래 표시된 코딩 패턴을 사용하면 필요한 코드보다 많은 이진 코드가 생성되어 애플리케이션에 부정적인 영향을 미칠 수 있으므로 사용하지 않도록 해야 합니다.When working with Windows Runtime objects, you should avoid the coding pattern shown below because it can have a negative impact on your application by causing more binary code than necessary to be generated.

anobject.b().c().d();
anobject.b().c().e();
anobject.b().c().f();

Windows 런타임 환경에서는 컴파일러가 c()의 값 또는 간접 참조(‘.’)를 통해 호출된 각 메서드의 인터페이스를 캐시할 수 없습니다.In the Windows Runtime world, the compiler is unable to cache either the value of c() or the interfaces for each method that's called through an indirection ('.'). 조치를 취하지 않으면 더 많은 가상 호출과 참조 계산 오버헤드가 발생합니다.Unless you intervene, that results in more virtual calls and reference counting overhead. 위의 패턴은 엄격하게 필요한 코드보다 두 배 많은 코드를 쉽게 생성할 수 있습니다.The pattern above could easily generate twice as much code as strictly needed. 가능한 경우 항상 아래에 표시된 패턴을 대신 사용하는 것이 좋습니다.Instead, prefer the pattern shown below wherever you can. 이 패턴은 훨씬 적은 코드를 생성하며, 런타임 성능도 크게 개선할 수 있습니다.It generates a lot less code, and it can also dramatically improve your run time performance.

auto a{ anobject.b().c() };
a.d();
a.e();
a.f();

위에 표시된 권장 패턴은 C++/WinRT뿐만 아니라 모든 Windows 런타임 언어 프로젝션에 적용됩니다.The recommended pattern shown above applies not just to C++/WinRT but to all Windows Runtime language projections.

탐색 등을 위해 문자열을 형식으로 변환하려면 어떻게 하나요?How do I turn a string into a type—for navigation, for example?

탐색 보기 코드 예제(대부분 C#으로 작성됨)의 끝에 이 작업을 수행하는 방법을 보여 주는 C++/WinRT 코드 조각이 있습니다.At the end of the Navigation view code example (which is mostly in C#), there's a C++/WinRT code snippet showing how to do this.

GetCurrentTime 및/또는 TRY를 사용하여 모호성을 해결하려면 어떻게 하나요?How do I resolve ambiguities with GetCurrentTime and/or TRY?

winrt/Windows.UI.Xaml.Media.Animation.h 헤더 파일에서 이름이 GetCurrentTime인 메서드를 선언하며 windows.h(winbase.h를 통해)에서는 GetCurrentTime이라는 매크로를 정의합니다.The header file winrt/Windows.UI.Xaml.Media.Animation.h declares a method named GetCurrentTime, while windows.h (via winbase.h) defines a macro named GetCurrentTime. 두 개가 충돌하는 경우 C++ 컴파일러에서 "오류 C4002: 함수 형식 매크로 호출 GetCurrentTime에 대한 인수가 너무 많습니다. "를 생성합니다.When the two collide, the C++ compiler produces "error C4002: Too many arguments for function-like macro invocation GetCurrentTime".

마찬가지로 winrt/Windows.Globalization.h에서 TRY라는 이름의 메서드를 선언하며 afx.h에서는 GetCurrentTime이라는 매크로를 정의합니다.Similarly, winrt/Windows.Globalization.h declares a method named TRY, while afx.h defines a macro named GetCurrentTime. 이들이 충돌하면 C++ 컴파일러에서 "오류 C2334: '{' 앞에 예기치 않은 토큰이 있습니다. 명백한 함수 본문을 건너뜁니다. "를 생성합니다.When these collide, the C++ compiler produces "error C2334: unexpected token(s) preceding '{'; skipping apparent function body".

두 문제 중 하나 또는 둘 모두 해결하려면 다음을 수행할 수 있습니다.To remedy one or both issues, you can do this.

#pragma push_macro("GetCurrentTime")
#pragma push_macro("TRY")
#undef GetCurrentTime
#undef TRY
#include <winrt/include_your_cppwinrt_headers_here.h>
#include <winrt/include_your_cppwinrt_headers_here.h>
#pragma pop_macro("TRY")
#pragma pop_macro("GetCurrentTime")

참고

이 항목에서 질문에 대한 답변을 찾지 못한 경우, Visual Studio C++ 개발자 커뮤니티를 방문하거나 Stack Overflow의 c++-winrt 태그를 사용하여 도움말을 찾을 수 있습니다.If this topic didn't answer your question, then you might find help by visiting the Visual Studio C++ developer community, or by using the c++-winrt tag on Stack Overflow.