> -----Original Message----- > From: fpc-devel <fpc-devel-boun...@lists.freepascal.org> On Behalf Of > Martok > Sent: Saturday, 30 June 2018 03:15 > To: fpc-devel@lists.freepascal.org > Subject: Re: [fpc-devel] Managed Types, Undefined Bhaviour > > Okay, then why does the calling convention change matters so much? > > Maybe a COM/CORBA thing? COM interface methods can't logically not be > virtual, and the kind of code from my example has always worked (for > me!) in FPC. > > I am confused. Which sorta ties in to the whole "surprises" thing > from before we hijacked this thread...
The compiler, when building the interface VMT for a specific interface as implemented by a specific class requires that the signature of the method in the class matches the signature of the method in the interface definition. So if the _AddRef and _Release methods in IInterface/IUnknown are using cdecl and the methods in the class are stdcall, it will ignore them. (Technically the compiler shouldn't need to do that, because it has to create trampolins for all interface methods anyway to fix up the self pointer, at which point any difference in calling convention could be accounted for). What I am surprised about is that the code with mismatched calling conventions compiles at all, and decides to use TInterfacedObject._AddRef (which has the correct calling convention) when building the Interface VMT, instead of producing a compiler error saying that TChainer._AddRef has a mismatching calling convention. I would not have expected that and it feels like a bug to me. _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
