Is it safe to use C++ "operator new" rather than CoCreateinstance to create a COM object?
c++, com
Solution
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.
Problem
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: 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. 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. 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!