search

microsoft / cppwin32

A modern C++ projection for the Win32 SDK
MIT License
441 stars 30 forks source link

Need to work out how to resolve WinRT types. #2

Open DefaultRyan opened 3 years ago

DefaultRyan commented 3 years ago

In the current metadata, we are seeing references to some WinRT types:

In order to generate the correct code to deal with these types as parameters (e.g. CreateDispatcherQueueController), we need to be able to resolve those types. At the moment, these types are all interfaces or runtimeclasses, so we can work around the lack of a definition for now, and use other definitions

What's worse, is that for these APIs to be truly usable, the calling code needs to have some notion of a type definition. Right now, there is no such thing as win32::Windows::Foundation::IPropertyValue, and it seems unlikely to ever change - we already have a first-class projection of WinRT types in C++/WinRT.

So, we have three alternatives as I see it:

  1. Interop with C++/WinRT, and perhaps even converge/merge with that projection. The lightest version would be when we encounter those types to generate the #include statements for the C++/WinRT headers - but this doesn't seem like a great user experience if the user doesn't know about nor wish to use C++/WinRT. So, this path strongly leads towards some sort of merge in our future.
  2. Generate a minimal "Win32" version (i.e. pared-down) of the needed WinRT types, sort of how the official SDK refers to types in the ABI namespace.
  3. Don't do much of anything at all, and leave these WinRT types as forward declarations only.
MarkIngramUK commented 3 years ago

(3) seems like the safest route, with users being able to access the types via C++/WinRT includes. However, then it makes it feel that the C++/Win32 projection isn't a "full" projection, and instead you have to rely on another projection to get the "full" API set? It'd be nice if users only had to depend on the Win32 includes, even if it leads to some duplication.

JaiganeshKumaran commented 3 years ago

Why not merge C++/WinRT and this one and rename to C++ for Windows?

DefaultRyan commented 3 years ago

Why not merge C++/WinRT and this one and rename to C++ for Windows?

I believe that's pretty much the plan for now.

MarkIngramUK commented 3 years ago

That would be great, I would much prefer to only depend on 1 projection.

mediabuff commented 3 years ago

If they are merged, I hope it’s an opt-in

LeonarddeR commented 3 years ago

I think merging the projections would also mean that PyWinRT can be modified pretty easily to support the Win32 projection as well, as PyWInRT seems to be based on the C++ WinRT projection currently?