3

I'm looking at some Direct3D code for WinRT and notice in there "ref classes" there using "ComPtr<ID3D11Device1>" instead of "ID3D11Device1*". So my question is do you HAVE to use "ComPtr" in a "ref class" or can you use a "native pointer" instead??

Right now i'm using a native pointer in a ref class as my c++ files are also used to compile Managed C++ as well. But sometimes I get odd behavior in WinRT and think it might have something to do with ComPtr.

zezba9000
  • 3,247
  • 1
  • 29
  • 51

1 Answers1

4

It is not necessary to use, but often very convenient.

It is reference counting smart pointer for COM objects that manages the lifetime of a COM object. If you use raw pointer you often can't guarantee that the COM object is still alive. If you think this could be related to your issue (e.g. you get access violation when calling COM methods) then it makes sense to use them. Performance penalty for reference counting is nothing compared to COM method invocation anyway.

nogard
  • 9,432
  • 6
  • 33
  • 53
  • So basically if I create a temporary ComPtr in the method Foo()... Then set my GLOBAL object* = ComPtr.Get() and leave the method Foo() ComPtr will auto release object* ?? This would explain the issues im having. – zezba9000 Sep 23 '12 at 11:46
  • @zezba9000: Yes, it will destroy COM object in this case. For global object I definitely recommend to use ComPtr – nogard Sep 23 '12 at 11:50
  • Thanks for the info. I removed all uses of ComPtr as my API is already setup to handle memory trashing. I still seem to have some issue with D3D11 in Metro though. – zezba9000 Sep 23 '12 at 12:39
  • Found out I was trying to reference some managed memory that came from C# and it was getting garbage collected. Now both my problems are solved :) – zezba9000 Sep 23 '12 at 13:46