On 20 July 2017 at 15:00, Jacek Caban jacek@codeweavers.com wrote:
This commit takes an approach similar to the earlier commit fabfa59aea5c5b3201142382038beb3e76cb7567: For ABI compatibility the return pointer is listed as an explicit parameter in the vtbl entry, while an inline helper is provided for source code compatibility.
While it fixes the problem for C++ callers, it breaks building classes implementing those interfaces. Implementation will try to override inline function instead of virtual one.
I does mean C++ implementations would need to explicitly list the return pointer as well, yes. I'm not aware of a way around that, aside from using a fixed compiler.
Given that the workaround has bad side effects, I'd say that we should at least try harder to not use it. For example it could be #ifdefed to not be used by compilers doing the right thing.
That's fine with me in principle, but see below. It also implies writing detection code for the bug.
With that, using our headers would require modifications in compiled code compatible with MSVC, so there would be a point in having a nice to use macro that interface implementations could use to decide if they should apply needed changes.
But if you have to make (minor) modifications to implementations, is that really any better than just explicitly listing the return pointer in the implementation? (Regardless of how easy/hard/ugly such a macro would need to be.)