Re: distributing a COM library/server for use by other folks for C++
"Vi2" <sharachov@hotmail.com> wrote in message
news:1151639732.094095.165420@x69g2000cwx.googlegroups.com
Igor Tandetnik ?????(?):
Non-automation compatible interfaces should not be put into a type
library in the first place. TLB format cannot represent all the
subtle details, so in worst case #import will (appear to) work but
_generate headers that don't match the original interfaces_.
It seems that this is very strong statement. TLB-driven marshaling
code cannot exactly marshal the non-automation compatible interfaces,
but I cannot say that #imported interface doesn't match (or
correspond to) the original interface. In terms of C|C++, of course.
You have the refuting examples, not?
If you have a pair of methods designated as [local] and [call_as], with
different parameters, then the TLB (and the #import-generated header, of
course) contains only the [call_as] part, but your vtable contains only
the [local] part. E.g.
// IDL
interface ITest : IUnknown {
[local]
HRESULT Local(long x);
[call_as(Local)]
HRESULT Remote(double x);
};
// MIDL-generated header
MIDL_INTERFACE("5FFDE818-48AE-4A19-8BF2-30080D81347E")
ITest : public IUnknown
{
public:
virtual /* [local] */ HRESULT STDMETHODCALLTYPE Local(
long x) = 0;
};
// #import-generated .TLH file
struct __declspec(uuid("5ffde818-48ae-4a19-8bf2-30080d81347e"))
ITest : IUnknown
{
//
// Raw methods provided by interface
//
virtual HRESULT __stdcall Remote (
double x ) = 0;
};
--
With best wishes,
Igor Tandetnik
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going to
land, and it could be dangerous sitting under them as they fly
overhead. -- RFC 1925