windows phone 8 - How are C# and C++/CX objects related? -
i have wp c++ runtime component consumed c# wp application.
in c++ runtime component, have
public interface class icallback { public: virtual void dosomething(); }; public ref class windowsphoneruntimecomponent sealed { public: windowsphoneruntimecomponent(); void setcallback(icallback ^callback); imap<platform::string^, platform::object^>^ createdictionary(); };
in c# application, have callbackimp
, implements icallback
. do
callbackimp cb = new callbackimp (); windowsphoneruntimecomponent com = new windowsphoneruntimecomponent(); // set callback com.setcallback(cb); // dictionary idictionary<string, object> dict = com.createdictionary();
i have following questions
- cb , com managed objects. c++/cx objects? i've heard cb , com point c++/cx objects (which reside on native heap), right ?
- if cb , com released .net gc, how c++/cx objects released then?
- when pass cb runtime component, cb belongs managed or native heap ?
- where dict reside? release it?
there no relationship whatsoever. c++/cx pure unmanaged language extension, designed make interop winrt types easy. com types under hood. syntax resembles managed c++/cli language lot, because designed solve same problem, making interop unmanaged types easy.
something similar happens in c# code well. less visibly, c# component exposing managed type unmanaged winrt type. taking advantage of language projection built clr. in turn takes advantage of existing com interop built clr. not entirely invisible, must example declare c# class sealed, restriction brought on com supporting interface inheritance, not implementation inheritance. , various other tidbits, having use datetimeoffset instead of datetime, side-effect of language projection mapping datetimeoffset. etcetera.
so addressing questions:
- there no c++/cx objects here, implementation detail of com server. underlying low-level api create winrt objects rocreateinstance(), same animal com cocreateinstance() function. uses class factory object created. object owned server, isn't exposed @ other code beyond normal com interface pointers.
- memory managed in com, , winrt, reference counting. iunknown::addref() adds reference, iunknown::release() releases reference. server destroys object when last release call decrements count 0. addref() call automatically generated ref new or object reference assignment statement in c++/cx code, release() auto-generated compiler when c++/cx reference goes out of scope. exact same behavior ccomptr , _com_ptr_t wrapper classes you'd use in com code difference compiler takes care of instead of having create smart pointer yourself. additional detail removes managed object reference held ccw. which, eventually, allows gc garbage collect c# object.
- the cb object exists on gc heap. noted above, com exposes interface pointers, winrt agnostic of object lives. class factory , iunknown methods hide detail
- same 3.
Comments
Post a Comment