How should I create classes in ATL project?

Question

I'm writing an ATL project and I wonder how should I create classes here. Right now I have one class created by Add/Class/ATL Simple Object. I want to divide it to smaller classes but method from this classes should use CComPtr and have CComPtr as an argument. I can't create 'simple' c++ class because I don't have CComPtr there.

Should I create ATL classes by ATL Simple Object Wizard and then use interface for this class to call methods. Like here:

CComPtr<ITestAtlClass> tptr;
tptr.CoCreateInstance(CLSID_TestAtlClass);
tptr->test();

And should I add all public methods by Class View/ITestAtlClass/Add/Add Method? What about constructors? Do I must initialize my class only by properties (and add them by Class View/ITestAtlClass/Add/Add Property)? And pass every com object by IUnknown interface?

Can somebody tell me how it should be done in ATL project. I will use this smaller classes internally (nobody will create this classes outside my DLL) just to make my code more readable.

Answer 1

I don't understand your comment that you can't use CComPtr from a simple C++ class. Can you please clarify?

I see two strategies:

• build a clean C++ object model that solves the problem, and then wrap it in a thin facade layer of one or more COM objects
• Use ATL classes throughout, and use CComObject<> and derivatives to instantiate and maintain these without the overhead of CoCreateInstance and the limitations of only using public interfaces.

The first one is usually much nicer, but if you're building a data-heavy object model, the second can be a useful technique.

If you have an ATL COM class called CVehicle, that derives from CComObjectRootEx<> and friends, you can instantiate it like so;

   CComObject<CVehicle>* vehicle = NULL;
   CComObject<CVehicle>::CreateInstance(&vehicle);

   vehicle->AddRef();

   // To get at any of its interfaces, use:
   CComPtr<ICar> car = 0;
   vehicle->QueryInterface(&car);

   // And to delete object, use:
   vehicle->Release();

There's also variations on CComObject<>, e.g. CComObjectStack<> that use different allocation and reference counting strategies.

As you can see, this is pretty messy. If you can explain what you mean by your comment on not being able to use CComPtr, maybe I can expand on that.