I'm new to Microsoft's way of doing things since I'm a Linux person so apologies if this is a stupid question. I've done a search but didn't see anything that addressed this. I've been tasked with rewriting plain C++ code to Windows COM. Is there an easy way to convert plain C++ to Windows COM other than rewriting the code as some sort of ATL object using Visual Studio? From prelim reading, the latter may be the way of least resistance without implementing IUnknown and setting the Connection Points by hand. Any advice would be much appreciated.
Sorry for wrong terminology/unclear explanation. I have some source files which implement various classes and one main class that's written in pure C++. Only the C++ devs use them and TPTB would like to make it so other devs use them so COM was determined to be the way to go. Easiest thing I can see from my readings is to throw everything into an ATL project and make a DLL. So mainly looking for suggestions on the easiest way to make the code COM compliant.
Easiest thing I can see from my readings is to throw everything into an ATL project and make a DLL.
That depends on what you have.
COM just defines interfaces between system components. So you shouldn't expect to wrap all your classes with a COM interface, just those at the system boundaries.
You should be aware that COM pushes memory management unto the user. This is managed with ATL, but it's not perfect. You can get leaks that are neigh impossible to fix. In my view, you should only use it if you have to.
I love COM, but I fear it is difficult for most folks. It excels in terms of 'componentizing'/encapsulating objects, and in terms of inter-language interoperability. Versioning is also very good.
When 64 bit entered the picture, I experimented with it and found everything translated perfectly. Of course it should, but what should isn't always what happens :)
Essentially, COM represents a whole different object model or paradigm from the one C++ uses. It doesn't really emphasize code reuse through inheritance as does typical C++ development. The main thing it does is provide a standardized memory layout or 'standard' for objects so that an object created in one language can be understood by another. That's where interfaces come in. In your existing code you might want to do as kbw said and look for the interfaces between objects. If you could break the code down into 'inteernal code' and outside interface code, you would be a long way to solving your problem.
It might be noted that a major concept within OLE/COM is IDL or 'Interface Definition Language'. Its a standardized C like language used to specify object interfaces. It gets compiled by MIDL.exe - Microsoft's Interface definition language compiler, and the binary output becomes a resource added to the binary object - usually a dll. When the dll is 'Registered' in the Windows Registry, the object with its interfaces and methods become visible in various object viewers associated with any number of programming languages such as .NET, Java, PowerBASIC, etc., etc.
As far as ATL - I've mixed feelings about that. I know its the 'C++ Approved' and recommended way to go, but I never used it very much. But that's just me. I don't like to 'cookbook' stuff and have code that's nothing but complicated macros I don't really understand. So I've always attacked COM strictly low level writing my own code. But I don't think that's for everybody.