A customer was porting some C++/CX code to C++/WinRT and one of the things they did was change the nonstandard C++/CX sealed
keyword to the standard final
keyword. They were a bit too aggressive about applying the final
keyword, though, because they were getting this compiler error:
Code | Description | File | Line |
---|---|---|---|
C2338 | C++/WinRT implementation types must not be final | base.h | 7759 |
The customer wanted to know which class was the one that was erroneously declared as final
. Can C++/WinRT be improved so the error message includes the name of the bad type?
Okay, so second question first.
This error message is generated by a static_assert
, and the rules for static_assert
say that the message must be a string literal. It cannot be created dynamically. The error message is fixed; you can’t incorporate any compile-time information into it.
However, not all is lost.
If you look at the full error log, you can see that the compiler does tell you which class is the bad one:
base.h(7759,29): error C2338: C++/WinRT implementation types must not be final contoso.cpp(556): message : see reference to function template instantiation 'auto winrt::make<winrt::Contoso:: implementation:: Widget>(void)' being compiled
This is a multi-line error message, but the Visual Studio error summary shows you only the first line. You have to flip to the Output window to see the second line, and that second line tells you where the problem is: The error message is coming from make<winrt::
, and that gives you a strong clue that the problem is with winrt::
.
You can also get the information by reading the second error message:
Code | Description | File | Line |
---|---|---|---|
C3246 | ‘winrt::impl::heap_implements<D>’: cannot inherit from ‘winrt:: |
base.h | 7685 |
The full error text also tells you the identity of the bad base class:
base.h(7685,1): error C3246: 'winrt::impl::heap_implements<D>': cannot inherit from 'winrt::Contoso:: implementation:: Widget' as it has been declared as 'final' with [ D=Contoso:: implementation:: Widget ]
One of my biggest frustrations when onboarding junior developers is convincing them that they need to keep the output window open and not just rely on the error window because it lacks context and sometimes has incomplete messages.
Though aren’t you going to talk about why a C++/WinRT implementation class can’t be
final
, and whatwinrt::impl::heap_implements
is and what its purpose is? I don’t think it’ll be easy for the programmer to find the answer without reading that specific blog post by Kenny Kerr.This was to disallow putting the WinRT implementation type on the stack or inside a C++ smart pointer type that's incompatible with the COM reference counting model.
In C++/WinRT version 1, all these would compile and were a significant source of bugs. Even the code generated by the XAML compiler did this mistake.
<code>
To prevent instantiating the type directly like this and ensure you go through winrt::make or winrt::make_self, in C++/WinRT version 2, they made the base...