[PATCH 5/5] widl: Generate helper macros for WinRT implementation.

[Jacek Caban]

On 19.02.2021 18:18, Rémi Bernon wrote:
> Hi Jacek!
>
> On 2/19/21 5:48 PM, Jacek Caban wrote:
>> Hi Rémi,
>>
>>
>> On 19.02.2021 12:04, Rémi Bernon wrote:
>>> This generates additional macros to help keeping implementation simple,
>>> guarded with WIDL_USING ifdefs, like this:
>>>
>>>      #ifdef WIDL_USING_WINDOWS_FOO_IFOO
>>
>>
>> I would find it more readable if we didn't follow all-uppercase for 
>> macro rule here, something like:
>>
>> #define WIDL_using_Windows_Foo_IFoo
>>
>> But it's a matter of taste, so I'm mentioning it just for consideration.
>>
>
> Yeah I don't really like it much, but I can see one reason to make 
> something like that, which would also possibly solve the [1] below:
>
> For making things simpler to type, it could just be the type C name 
> prefixed by WIDL_USING_, like in:
>
> #define WIDL_USING_CWindows_CGaming_CInput_CIRawGameController
>
> The generation of the guard macros would just have to remove the 
> __x_ABI_ prefix, and developers just need to copy paste the type names 
> they want without having to remove the C prefixes or mess with the 
> name case.


I hope that we can save developers from dealing with details about name 
mangling, at least in non-templated cases. Ideally they would be able to 
type it manually.


> I was afraid of making its scope too large, in case there's some types 
> which would conflict together. I think having it per type is a bit 
> verbose but at least it stays under control.


Sure, we may have both mechanisms: use per-namespace macros whenever 
possible and fallback to per-type macros in problematic cases.


> Could it be added later, if we need to implement a large amount of 
> WinRT DLLs where adding each type proves too verbose? 


Maybe we could implement only per-namespace macros and wait for an 
actual collision problem before implementing per-type variant?


Thanks,

Jacek