Re: HRESULT only required for Automation-compatible interfaces?
"Boris" <boris@gtemail.net> wrote in message
news:op.t2zqpgfq45fww6@burk.mshome.net
Igor, I've been playing around with [local] but didn't get far. The
problem is that when I create a [local] interface which is neither
Automation-compatible nor cares about marshalling I end up using
datatypes MIDL doesn't like (because it doesn't know them).
Even in a [local] interface, you are still limited to MIDL types (note
that not all types MIDL supports are automation-compatible).
Here's an
example:
[local, ...]
__interface IBarLocal
{
std::string GetString();
};
You seem to be using ATL attributes. Don't do that - they are buggy.
Redo your project as non-attributed.
You don't have to define your interfaces in IDL. You can just hand-craft
an .h file. At the end of the day, an interface is just a C++ class with
no data members and all methods pure virtual. IDL is primarily useful
for generating marshalling support - but you explicitly don't want it.
Now, an interface using C++ classes (such as std::string) is rather
ill-advised. You are not really doing COM anymore (though you can get
away with it under certain restrictions). For example, if the COM object
implementing this interface is in a DLL, and the client in an EXE, the
two must be compiled by the same version of the same compiler and linked
to the same flavor of CRT DLL (otherwise, binary layout of the string
class could be different in the two modules, and/or memory allocated in
one module could not be freed in the other). This kind of defeats the
point of COM.
MIDL-compatible data types are there for a reason: they have
well-defined binary layout and memory management protocol associated
with them. COM, being a binary standard, relies on both.
--
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