Question

this is probably a noob COM question, but googling this raises more questions than providing answers:

Is it safe to use “operator new” instead of CoCreateInstance for a local COM instance?

What I’ve done:

1. I implemented the IOperationsProgressDialog interface
   http://msdn.microsoft.com/en-us/library/windows/desktop/bb775368(v=vs.85).aspx
   by using public inheritence and thereby also implemented the IUnknown interface.

2. I created an instance via “new RecyclerProgressCallback” and put it into a COM-Ptr for life-time management. “RecyclerProgressCallback” is the name of my derived class.

3. I’m using this instance in IFileOperation::SetProgressDialog
   http://msdn.microsoft.com/en-us/library/windows/desktop/bb775803(v=vs.85).aspx

Summary: My approach “seems” to work, but I don’t trust it, there’s just too much disconcerting information around COM object creation to rely on the observable behavior only.

Are there any subtle risks, fallacies or other problems? Thanks!

Answer 1

I’ve even put them on the stack. Andrey’s answer (now deleted) incorrectly suggested that it is unsafe, because you bypass COM reference counting. This is faulty reasoning. COM doesn’t count references; it delegates the responsibility to you. You have to call delete, or free(), or whatever your language uses, after COM calls your Release method on its last interface. The important word is after. Not when, because you’re not obliged to do so immediately.

Similarly, CoCreateInstance is a long detour because COM is language-neutral and doesn’t know whether an object must be created with malloc or new. You do, so just bypass the whole COM logic.