I was assuming that, but as you point out making foo virtual kills it.
static_cast performed a pointer adjustment. Also I avoid using
multiple inheritance.
it properly.
Thanks for the help, much appreciated.
pIFoo) and then gain access to the CFoo member variables. The purpose
of this was to create a kind of copy constructor for COM.
interface that exposes everything I need.
spforeman <google@sforeman.com> wrote:
Thanks for the reply but I'm afraid I still don't see why it doesn't
work. I understand what you are saying about the cast and totally
agree that if they were completely separate objects then pSpot would
be garbage. But (and this is where I might have things muddled) they
are not sepeare objects...are they? Doesn't CSpot derive from ISpot
via IDispatchImpl?
So? You seem to assume that if class D derives from class B, then two
pointers D* and B* (referring to the same object) must always point to
the same address. This is only the case with very simple inheritance
hierarchies, involving neither virtual functions nor multiple
inheritance. Try this program:
class B {
public:
virtual void f() {}
};
class D : public B{
};
int main() {
D* pd = new D;
B* pb = pd;
printf("%x, %x\n", (unsigned)pd, (unsigned)pb);
delete pd;
return 0;
}
You'll see two different numbers printed (I expect them to be 4 bytes
apart).
I'm very new to COM so maybe it isn't as simple as I think. I see it
like this:
class ClassA : public ClassB
{
public:
void foo();
};
ClassB* myClass = new ClassA();
Bar(myClass);
void Bar (ClassB* pMyClass)
{
ClassA* pClassA = reinterpret_cast<ClassA*>(pMyClass);
pClassA->foo();
}
This should work fine (not the best code, but it would work).
Try making foo virtual, see how well it would work then. Make foo
actually use some member variables in its class (otherwise it might
appear to work even though it's given a bogus 'this' pointer).
My
understanding is that I am doing this in COM
Precisely.
(maybe the QueryInterface
should be replaced with a dynamic_cast) - so maybe there is something
COM related that I am not understanding that stops it from being a
valid thing to do?
Nothing to do with COM - your code is broken in plain vanilla C++, too.
What I am ultimately trying to achieve here is that I want to call a
function of CSpot from within the C code. I thought I could retrieve
the CSpot* from the ISpot* so that I could do this.
As a quick fix, do static_cast instead of reinterpret_cast. static_cast
performs necessary pointer adjustments.
However, I don't recommend this approach long term. It assumes that
ISpot* pointer comes directly from your implementation C++ class. This
may not be the case for two reasons:
- as a client, what's to stop me from writing my own object implementing
ISpot and passing it to you as a parameter? After all, your interface
promises to accept any ISpot* pointer, not just one retrieved from you
earlier.
- practically speaking, the situation above happens in the presence of
marshalling. E.g. if your design ever changes so that ISpot
implementation is in one EXE instance while the method taking ISpot
pointer is in another (or the two are in different apartments within the
same EXE), what the method actually gets is a pointer implemented by
proxy object, not by your C++ class. Casting would then lead to a rather
spectacular crash.
I recommend the following approach: all the functionality that some
other COM object might need (even if that other object is implemented in
the same executable) should be exposed via COM. If you don't want it
available to all the clients via public interfaces, define and implement
a separate interface exposing this functionality, don't document it
anywhere. In the other object, just query for this private interface and
call its methods normally.
--
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