c++ - Is it safe to cast a IDispatch* into an IUnknown*, without using QueryInterface, for interprocess COM objects? -

when dealing interprocess com objects, safe cast idispatch* iunknown*, without using queryinterface ?

here our idispatch object comes other process otherprocess.exe. , colleague of mine says should call queryinterface on idispatch iunknown.

currently i'm doing:

void ccomthrowdispatch::checkcomavailabilty() const {     iunknown * piunknown = m_spdispatchdriver.p;        // line above problem ?      // m_spdispatchdriver atl ccomdispatchdriver      // handles object instanciated in process.     // m_spdispatchdriver.p of type idispatch*      if (piunknown == nullptr) return;     bool bcomobjectreachable = ::coishandlerconnected(piunknown) == true;     if (bcomobjectreachable == false)     {         throw myexception;     } } 

my problem suggestion: dealing cases (access violations) when otherprocess.exe has crashed or has been killed. seems calling functions invoke on idispatch encapsulates objects no longer exisiting otherprocess.exe provokes these access violations (edit: comments , answers reveals latest assumption false!).

that's why i'm trying protect application testing ::coishandlerconnected(piunknown); takes iunknown parameter.

but calling queryinterface on idispatch, colleague advises me do, afraid fall in same problem trying solve: idispatch handles object no longer exists, , queryinterface iunknown undefined behaviour same (edit again, assumption false).

am wrong when cast ? common way deal dead interprocess com objects ?

this begining of definition of idispatch in oaidl.h, declared deriving iunknown.

midl_interface("00020400-0000-0000-c000-000000000046") idispatch : public iunknown { public:     virtual hresult stdmethodcalltype gettypeinfocount(          /* [out] */ __rpc__out uint *pctinfo) = 0; 

casting idispatch iunknown in c++ (like static_cast<iunknown*>(pdispatch)) yields same pointer value, because idispatch derives iunknown. otoh, doing queryinterface iid_iunknown on pdispatch may return different pointer, it's still legit operation. in fact, how identity of com object, say, check if 2 interfaces implemented same com object (a hard com rule work inside same com apartment).

that said, proxy com object implemented com marshaller may caching interfaces, call idispatch::queryinterface may return s_ok , valid iunknown identity of proxy, despite remote server went down. is, such operation might not causing instant ipc call.

in case, test if com server still alive , well, i'd call idispatch::gettypeinfocount on proxy object have. cause ipc call (or round-trip on wire, if server runs on different host).

in case remote server has crashed or unavailable, you'd receive co_e_objnotconnected error (could perhaps different error code, not s_ok).

note though, doing ipc call check if server available might costly operation, depending on scenario.