I'm working on a fairly large project written primarily in C++ using MFC. We are tasked to gradually port this application to use Qt. Years ago, a wrapper around much of our functionality was written using COM. I feel using the COM wrapper from the new Qt code will help isolate code that would force dependencies on MFC. Unfortunately, we're also being asked to ween our use of COM/ActiveX. So, introducing new consumers of our COM wrapper in Qt isn't ideal. Visual Studio has a class wizard that will generate a C++ class based on an interface in a TLB file, but it's dependent on MFC and the interface still exposes COM (LPDISPATCH, SAFEARRAY*, etc).
With all that said, does anyone know of a tool (free or commercial) that will take a Microsoft IDL file and convert it to C++, who's interfaces aren't dependent on MFC nor COM?
and working with the code generated by midl.exe
That's hang-up number one. Midl.exe does not generate code, it only generates declarations. Pure virtual classes in C++, only method declarations with no implementations. Either to a .h file or to a .tlb type library file. The type library is handy because it is easy to read by tooling, having a restricted sub-set of COM called Automation. And implemented by just about any language runtime on Windows.
Key point is that these are just declarations, the glue that makes code written in different modules and/or different languages or class libraries work together. Very important in large projects, interfaces tie the pieces together.
Our system architect learned of our approach and advised that we find a way to not add these COM-specifics to our new Qt projects.
That's singularly unhelpful advice. "Don't do that" is something my doctor tells me when it hurts to put my arm behind my back. I can live with that, I have a good alternative and can just turn around. In your case I would have to demand more from the architect. He's messing with the body parts, he's separating the torso from the legs and head and feet and hands. Brain utterly disjointed. The very glue that makes the different chunks of code you have now work together. Break that interface and you'll seriously break your app, Netscape style.
Beware of the astronaut architect (another Spolsky favorite) that's happy to force you into something that he understands but doesn't have to implement. Demand a reasonable alternative, an architectural approach since breaking the interfaces has a deep architectural impact on your app. Those MFC classes that everybody implemented from the interfaces are pretty much junk when you change the interface. Rewriting them all into Q classes is going to seriously keep you unproductive for a while. And is devastatingly boring code to write. Only to produce the same thing, with more bugs. Things You Should Never Do, part 2.