Re: CComPtr strange behaviour
Alexander Lamaison <awl03@doc.ic.ac.uk> wrote:
On Mon, 27 Jul 2009 12:59:48 -0400, Igor Tandetnik wrote:
Now, it's possible that the problem is not with
CFolder::GetUIObjectOf, but with folder_item_object. There might be
an unspoken contract, which GetUIObjectOf relies on, that
folder_item_object returns not just any IUnknown, but specifically an
IUnknown that is an upcast from the interface identified by riid (so
that the correct pointer can be obtained with a downcast).
There is more than one IUnknown? Huh?
Of course. You have a class derived from several interfaces, each of
which is derived from IUnknown. So you derive from IUnknown multiple
times, indirectly. This example may prove illuminating:
class Unknown {
virtual void X() {} // just to force a vtable
};
class Itf1 : public Unknown {};
class Itf2 : public Unknown {};
class ComObject : public Itf1, public Itf2 {};
int main() {
ComObject obj;
Unknown* unk1 = static_cast<Itf1*>(&obj);
Unknown* unk2 = static_cast<Itf2*>(&obj);
printf("%p %p\n", unk1, unk2);
return 0;
}
You've reached the limit of
my COM knowledge?
How should I know?
Why would there be more than one? I thought the
IUnkown* was used to determine object identity
Not just any IUnknown - the one returned by
QueryInterface(IID_IUnknown). Look at the implementation of
CComPtrBase::IsEqualObject - there's a reason for two QueryInterface
calls.
Also, I didn't think I was doing _any_ casting.
The caller of GetUIObjectOf does something like this:
IExtractIcon* pEI;
pFolder->GetUIObjectOf(IID_IExtractIcon, (void**)&pEI);
Note the (void**) cast: the pointer you put into *ppv better be
IExtractIcon*. Let's look at a piece of code that is equivalent to the
above but makes the downcast explicit:
void* pv;
pFolder->GetUIObjectOf(IID_IExtractIcon, &pv);
IExtractIcon* pEI = (IExtractIcon*)pv;
As far as I was
aware I was doing everything through QueryInterface.
You've assigned an IUnknown* to a void* which the caller expects to hold
IExtractIcon*. You tricked the caller into performing a downcast, by
violating your contract with it.
It's hard to decide who to blame, since you are not using common COM
argument-passing conventions (which imply a well-known set of rules)
I thought I was. Do you mean that I pass pointers directly as smart
pointers rather than in an out parameter and I use exceptions? Is
this fundamentally non-COM?
Well, COM doesn't do that, mainly because it is limited to C types, so
no smart pointers. I'm not saying what you are doing is wrong - it's
perfectly fine to use smart pointers internally, and revert to COM-style
parameter passing on module boundaries. However, since you can no longer
rely on widely known and well understood COM rules, you have to
carefully document your own.
In particular, when you have a function like this:
CComPtr<IUnknown> ObtainInterface(RIID riid);
is it expected that the resulting IUnknown* could be safely down-cast to
the interface represented by RIID, or is the caller required to QI for
it? In other words, is it specified which of (possibly many) IUnknown
subobjects the function returns a pointer to?
This highlights to me the absence of type safety in a
void** out-param. Out of curiosity, why do these functions ask for
void** rather than IUnknown**?
How is that more type-safe? If the caller does want to get
IExtractIcon*, how would it get it from that IUnknown* pointer?
By QueryInterface.
You do realize that QueryInterface takes void** as a parameter? Is type
safety improved by shifting the cast elsewhere?
QueryInterface is the one function that should be allowed to take a
void** as it is effectively doing a checked cast to your desired
interface type. If all others take an IUnknown** and then the caller
QIs the result, it will be safe, if less efficient.
Sometimes, _much_ less efficient. In DCOM, a QueryInterface call must
actually travel over a network. This is a nontrivial overhead to add to
each and every COM call - every network roundtrip counts. It would also
make things like IMultiQI::QueryMultipleInterfaces impossible.
In any case, perhaps COM should have been done the way you suggest, but
it isn't. You'll have to play by the rules as they exist.
--
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