Replacement for #import in Visual C++

Question

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 #impor

Answer 1

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

Answer 2

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.

Answer 3

(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.

Answer 4

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.

Answer 5

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.

Answer 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.