The Windows::Foundation Windows Runtime namespace contains four types of asynchronous operation object. Windows Runtime async objects ( IAsyncXxx) An asynchronous method such as that-one that you don't wait on-is known as a fire-and-forget method. In that case it's more efficient for the asynchronous method not to return an asynchronous operation object. But sometimes you don't want or need to wait on the completion of work done asynchronously.A method that returns an asynchronous operation object is one that you can wait on. It's common to want to wait on the completion of asynchronous work before you do something else.Your project has methods that do work asynchronously, and there are two main kinds. So that we have a common frame of reference for asynchronous programming concepts and terminology, let's briefly set the scene regarding Windows Runtime asynchronous programming in general, and also how the two C++ language projections are each, in their different ways, layered on top of that. Some background in asynchronous programming
#CX PROGRAMMER JUMP CODE#
And once you've ported to C++/WinRT, the structure of your async code will then be easier to port to C#, should you wish to. If you don't have a C# version of your project, then you can use the techniques described in this topic. So C# code already essentially follows a philosophy of beginning with a synchronous version and then inserting await into the appropriate places. And then insert co_await (cooperatively await) into the appropriate places.įor that reason, if you have a C# (rather than C++/CX) version of the asynchronous code from which to begin your port, then that can give you an easier time, and a cleaner port. To deconstruct the often unnatural structure of PPL source code, we recommend that you first step back and understand the intent of the original code (that is, discover the original synchronous version). For example, loops become recursion if-else branches turn into a nested tree (a chain) of tasks shared variables become shared_ptr. And then that was translated into tasks and explicit continuations-the result often being an inadvertent obfuscation of the underlying logic. Often, an algorithm was originally written to suit synchronous APIs. And development teams routinely report that once they're over the hurdle of porting their asynchronous code, the remainder of the porting work is largely mechanical. The good news is that conversion from tasks to coroutines results in significant simplifications. There isn't a natural one-to-one mapping from PPL tasks to coroutines, and there's no simple way (that works for all cases) to mechanically port the code. Porting from C++/CX to C++/WinRT is generally straightforward, with the one exception of moving from Parallel Patterns Library (PPL) tasks to coroutines. The reason an entire topic is dedicated to asynchronous code interop For more info, see the topic Move to C++/WinRT from C++/CX. And for a XAML project, at any given time your XAML page types must be either all C++/WinRT or all C++/CX. If you have a Windows Runtime component project, then porting gradually is not possible, and you'll need to port the project in one pass.
There are some limitations to porting gradually from C++/CX to C++/WinRT. This topic about asynchrony builds on that info, and it uses those helper functions. It also introduces two helper functions that you can use to convert a C++/CX object into a C++/WinRT object (and vice versa).
#CX PROGRAMMER JUMP HOW TO#
That topic shows you how to prepare your project for gradual porting. The techniques allow you to make gradual, controlled, local changes along the path toward porting your entire project, without having each change cascade uncontrollably throughout the project.īefore reading this topic, it's a good idea to read Interop between C++/WinRT and C++/CX. You can use these techniques individually, or together. This topic focuses on techniques for interoperating between asynchronous C++/CX code and asynchronous C++/WinRT code. If you have asynchronous code, then you might need to have Parallel Patterns Library (PPL) task chains and coroutines exist side by side in your project as you gradually port your source code. If the size or complexity of your codebase makes it necessary to port your project gradually, then you'll need a porting process in which for a time C++/CX and C++/WinRT code exists side by side in the same project. This topic picks up where the topic Interop between C++/WinRT and C++/CX leaves off. This is an advanced topic related to gradually porting to C++/WinRT from C++/CX. Although we recommend that you read this topic from the beginning, you can jump straight to a summary of interop techniques in the Overview of porting C++/CX async to C++/WinRT section.
0 kommentar(er)
