Quote:It will "sort of" work. Shared pointers will not incrememnt/decrement the ref-count of the COM pointer (assuming you've set it up correctly, it'll increment the ref-count once when you first create a shared_ptr, then when all copies of that shared_ptr are destroyed, the ref-count will be decremented once).
Original post by chadsxe
It says shared_ptr can work with a custom deleter no?
Quote:I guess you got a point.
Original post by Codeka there's not much point (in my opinion) trying to shoe-horn shared_ptr into something it's not just for the sake of "consistency" or some other aesthetic reason.
//This template is only enabled if T is a subclass of IUnknown (i.e. a com pointer)template<typename T>void intrusive_ptr_add_ref( T* t, typename boost::enable_if<boost::is_base_of<::IUnknown, T> >::type* dummy=0){ t->AddRef();}//This template is also only enabled if T is a subclass of IUnknown (i.e. a com pointer)template<typename T>void intrusive_ptr_release( T* t, typename boost::enable_if<boost::is_base_of<::IUnknown, T> >::type* dummy=0){ t->Release();}namespace com{ //My proposed alternate of CComPtr. This version is unimplemented //so that we can explicitly designate which types the class should //exist for (namely, those types that derive from IUnknown) template<class T, class Enable=void> class ptr; template<class T> class ptr< T, typename boost::enable_if<boost::is_base_of<::IUnknown, T> >::type > { public: typedef boost::intrusive_ptr<T> type; private: //This prevents the common error of writing something like //com::ptr<IDirect3D9> var; //You must actually write //com::ptr<IDirect3D9>::type var; ptr(); ~ptr(); }; //The rest of what follows is used for prodiving a simplified //way of calling API functions that expect an Ixxxx** and returns //a newly allocated COM pointer with a ref count of 1. The normal //approach is to use CComPtr::operator&, but this is dangerous. template<typename T> typename ptr<T>::type take_ptr(T* t) { return ptr<T>::type(t, false); } template<typename T> class recv_ptr_t { public: recv_ptr_t(typename ptr<T>::type& r) : auto_(r), raw_(NULL) {} ~recv_ptr_t() {auto_ = take_ptr(raw_);} operator T**() { return &raw_; } operator void**() { return reinterpret_cast<void**>(&raw_); } private: T* raw_; typename ptr<T>::type& auto_; }; template<class T> recv_ptr_t<typename T::element_type> recv_ptr(T& rptr) { return recv_ptr_t<typename T::element_type>(rptr); } template<typename Dest, typename Src> ptr<Dest> query_interface(Src p, const IID& iid = __uuidof(Dest)) { void* pv = NULL; p->QueryInterface(iid, &pv); Dest* p2 = static_cast<Dest*>(pv); return ptr<Dest>(p2, false); }}com::ptr<IDirect3D9>::type d3d(::Direct3DCreate9(DX_SDK_VERSION), false);com::ptr<IDirect3DDevice9>::type device;d3d->CreateDevice( D3DADAPTER_DEFAULT, D3DDEVTYPE_HAL, NULL, D3DCREATE_HARDWARE_VERTEXPROCESSING, &present_params, com::take_ptr(device));Quote:
Original post by chadsxe
To be honest I can't really figure out what the pro's and con's are of one versus the other. Intrusive seems to remove the ref count all together. Beyond that I am open for some advice.
intrusive_ptr_add_ref(internal_ptr_);intrusive_ptr_release(internal_ptr_);Quote:
Original post by ApochPiQ
Yes, but the point is, you have to do extra work to make intrusive_ptr work correctly with COM's reference counting system. Can you at all justify doing that over using the CComPtr class which is already guaranteed to do the correct thing?
Quote:Indeed. "Can" does not equal "should".
Original post by ApochPiQ
Yes, but the point is, you have to do extra work to make intrusive_ptr work correctly with COM's reference counting system. Can you at all justify doing that over using the CComPtr class which is already guaranteed to do the correct thing?
Quote:
Original post by iMalc Quote:Indeed. "Can" does not equal "should".
Original post by ApochPiQ
Yes, but the point is, you have to do extra work to make intrusive_ptr work correctly with COM's reference counting system. Can you at all justify doing that over using the CComPtr class which is already guaranteed to do the correct thing?
Quote:
Original post by cache_hit Quote:
Original post by ApochPiQ
Can you at all justify doing that over using the CComPtr class which is already guaranteed to do the correct thing?
Absolutely.
_COM_SMARTPTR_TYPEDEF(ISomething, IID_ISomething);_COM_SMARTPTR_TYPEDEF(IOther, IID_IOther); // Create a new instance using CoCreateInstance()ISomethingPtr something = ISomethingPtr(CLSID_Something);// QueryInterface to another IIDtry { IOtherPtr other = something;}catch(const _com_error &error) { cerr << "QueryInterface failed with HRESULT = " << error.Error();}template<typename Class>inline CComObject<Class> *com_new() { CComObject<Class> *pInstance; CheckError(CComObject<Class>::CreateInstance(&pInstance)); return pInstance;}// Create an instance of a local ATL classISomethingPtr something = com_new<CSomeAtlCoClass>();// Take out the pointer without Release()ingISomething *raw = something.Detach();// Assign a new pointer without AddRef()ingsomething.Attach(new ManuallyImplementedCoClass());Quote:Ah actually I'm all too familiar with those as well. The problem is that even the VS2008 implementation of them misses some consts in it. For example the less-than operator uses the one parameter version and although it takes that parameter by const reference, the method itself isn't const. This causes much difficulty when trying to store a std::set of these etc.
Original post by Cygon
As far as I know, the latest answer to COM pointers in ATL are _com_ptr_t (and _bstr_t, _variant_t). This is also the pointer that's used for the ISomeInterfacePtr typedefs when you #import a COM DLL (#import is a Microsoft extension to VC++).
They work well in STL containers and you even get a clean solution for QueryInterface:
This topic has been locked by a moderator. New replies are not allowed.
With your permission, GameDev.net uses analytics cookies to understand how people use the platform. You can accept analytics or continue with necessary cookies only. Learn more