An opinionated comparison of C++ frameworks for consuming and implementing Windo...
source link: https://devblogs.microsoft.com/oldnewthing/20220606-00/?p=106713
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
An opinionated comparison of C++ frameworks for consuming and implementing Windows Runtime types
Raymond Chen
June 6th, 20223
There are three leading C++ frameworks for consuming and implementing Windows Runtime types. The current recommendation (as of this writing) is C++/WinRT.
| WRL | C++/CX | C++/WinRT | |
|---|---|---|---|
| Error handling | HRESULT-based |
Exception-based | Exception-based |
| Interop with C++ standard library |
Poor | Middling | Good |
| Code verbosity | Very high | Low | Low |
| Code generation | Small | Explosively large | Small |
| Compile time | Low | Low | High¹ |
| IDL file | Manually authored | Automatically generated² | Manually authored |
| Static class constructor³ | Supported | Not supported | Supported |
| COM static lifetime for factories⁴ |
Can implement manually | Cannot implement | Built-in |
| Default threading model | It’s complicated⁵ | Free | Free |
| Can choose nondefault threading model |
Yes | No | Yes |
| Language | Standard C++ | Nonstandard extension | Standard C++ |
| Static analysis tools | Supported | Not supported | Supported |
| Language standard required |
C++11 and higher | C++14 or C++17 with /await |
C++17 and higher |
| Forward compatibility | Compatible | Incompatible with C++20 | Compatible |
| XAML compiler support | No | Yes | Yes |
| Coroutine support | No | Yes via PPL⁶ | Yes |
| License/source code | Ships in SDK | Closed source | Open source |
| Support | Maintenance | None | Active |
Notes
¹ C++/WinRT contains a large number of types and template specializations, which slows down the compiler. The precompiled header file easily exceeds 1GB in size. You can define WINRT_LEAN_AND_MEAN to remove rarely-used features and improve compile times.
² Automatic generation of the IDL file is a two-edged sword. Although it saves a lot of effort, it can also get in the way: If you need to make a runtime class object marshallable, you need to register a marshaller for the autogenerated interface, which will have an ugly autogenerated name, and whose UUID may not be stable. Autogeneration also conflicts with versioning, makes it harder to interop with other languages, and it can result in puzzling behavior if you don’t understand how the autogeneration works. Furthermore, the autogenerated interface names do not follow Windows Runtime naming conventions.
³ Static class constructors allow class statics to be delay-initialized. This is significant because running constructors at DLL_PROCESS_ATTACH creates the risk of deadlocks and other unfortunate behaviors. C++/CX clients must work around this by having a static InitializeStatics() method which initializes the statics (e.g., dependency properties) and calling it at an opportune moment.
⁴ COM static lifetime allows you to register an object in the COM static lifetime store, which allows you to (1) obtain it later, and (2) destruct it automatically when COM is uninitialized. The former provides a persistent-lifetime object for things like global event sources. The latter permits the object’s destructors to run while COM is still initialized.
⁵ Default is normally free-threaded, but if BUILD_WINDOWS is set, then default is single-threaded.
⁶ PPL coroutine support is very large.
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK