Replacement for #import in Visual C++

问题:

We have large C++ project that we used to compile with the /MP switch to take advantage of multiple cores.

However, we recently brought in some code that uses #import on a couple of tlb's, and #import is incompatibile with /MP, which means we are back to single threaded builds and a lot more time to get coffee.

Any suggestions on how to get #import and /MP to play nice? Is there a tool that will statically generate the C++ headers from a #import as a pre-build step?

Update:

Following Matt's advice worked great. For anyone else stumbling over this in google:

1. create a separate static lib project
2. set up enough includes so you can put the #import statement in the lib project
3. make your main project dependent on the lib project (to ensure correct build order)
4. add the lib project's temporary build folder to the include path for the main project
5. #include the generated .tlh files where you were doing the #import
6. enable the /MP switch and lose the coffee break time...

回答1:

Why not just #include the generated headers created from #import?

回答2:

(I'm a little late to this question, but this is a problem near and dear to my heart.)

You could try to use the old-school way of accessing COM objects from C/C++. This involves the developers of the COM objects providing client-side .h files that have the C/C++ versions of the COM interfaces. These files look like simpler versions of what #import makes.

Where do these files come from? If the COM objects are written in C/C++ (VC++) than these come from the MIDL compiler. This command-line tool takes ODL/IDL files and creates C/C++ source code out of them. Some of what it emits is useful for client application.

If you have the source of the COM objects you may already have these files!

If you only have TLB files you can use OLE/COM Object Viewer (OLEVIEW.exe - came with at least VC++ 6.0) you open the type library and save-as and OLD/IDL file. Then run the MIDL compiler to generate the client-side C/C++ include files. There is an off-chance that a third party COM object may come with these files, but they often do not (I recall Crystal Reports did for awhile, then stopped shipping them - screwing us royally - but I digress).

Using ATL smart pointers (and other support classes) with the interface classes MIDL creates is almost at nice as what #import creates. It depends on how much of of the #import-specific features you use.

For /MP I have done both what I'm suggesting and some of what the accepted Matt Davison answer suggests.

回答3:

You can use the /MP option for the project as a whole, and then make an exception for a single file using the /MP1 option.

回答4:

If you can limit the number of files you are #import'ing, you can put these in the precompiled header file (eg stdafx.h) which is already automatically excluded from /MP. This avoids the issue mentioned, since all other files will wait to compiler until stdafx.cpp is completed, and would all 'inherit' the same #import'ed definitions.

回答5:

One option is to move the imports into a separate DLL and provide wrapper classes for them using an opaque pointer. Then disable /MP for that DLL only, and the rest of your build should be fine.

回答6:

You could split the project into two parts, one that more or less does the import disabling /MP and one that does everything else enabling /MP.

回答7:

http://msdn.microsoft.com/en-us/library/bb385193.aspx

MS says it's not compatible