Замена для #import в Visual C ++

Question

У нас есть большой проект C ++, который мы использовали для компиляции с ключом / MP, чтобы использовать преимущества нескольких ядер.

Однако недавно мы добавили некоторый код, который использует #import для пары tlb, и #import несовместим с / MP, что означает, что мы вернулись к однопоточным сборкам и намного больше времени для получения кофе.

Какие-нибудь предложения о том, как заставить #import и / MP играть хорошо? Существует ли инструмент, который будет статически генерировать заголовки C ++ из #import в качестве шага перед сборкой?

Обновление:

Следуя советам Мэтта, это прекрасно сработало. Для тех, кто спотыкается об этом в Google:

1. создать отдельный статический проект lib
2. установите достаточно включений, чтобы вы могли поместить оператор #import в проект lib
3. сделать ваш основной проект зависимым от проекта lib (для обеспечения правильного порядка сборки)
4. добавить временную папку сборки проекта lib в путь включения основного проекта
5. #include сгенерированных .tlh файлов, в которых вы выполняли #import
6. включить переключатель /MP и потерять время на кофе-брейк ...

Answer 1

Почему бы просто не #include сгенерированные заголовки, созданные из #import?

Answer 2

(Я немного опоздал на этот вопрос, но эта проблема близка и дорога моему сердцу.)

Вы можете попытаться использовать старый способ доступа к COM-объектам из C / C ++. Это включает разработчиков COM-объектов, предоставляющих клиентские файлы .h, которые имеют версии COM-интерфейсов C / C ++. Эти файлы выглядят как более простые версии того, что делает #import.

Откуда эти файлы? Если COM-объекты написаны на C / C ++ (VC ++), то они поступают из компилятора MIDL. Этот инструмент командной строки берет файлы ODL / IDL и создает из них исходный код C / C ++. Часть того, что он излучает, полезна для клиентского приложения.

Если у вас есть источник COM-объектов, возможно, у вас уже есть эти файлы!

Если у вас есть только TLB-файлы, вы можете использовать OLE / COM Object Viewer (OLEVIEW.exe - поставляется как минимум с VC ++ 6.0), вы открываете библиотеку типов и сохраняете как и OLD / IDL файл. Затем запустите компилятор MIDL, чтобы сгенерировать клиентские файлы C / C ++. Существует вероятность того, что сторонний COM-объект может поставляться с этими файлами, но они часто этого не делают (я вспоминаю, что Crystal Reports сделал какое-то время, а затем перестал их отправлять - пофиг на нас - но я отступаю ).

Использование интеллектуальных указателей ATL (и других вспомогательных классов) с интерфейсными классами, которые создает MIDL, почти не отличается от того, что создает #import. Это зависит от того, сколько из # специфичных для импорта функций вы используете.

Для / MP я сделал как то, что я предлагаю, так и кое-что из того, что предлагает принятый ответ Мэтта Дэвисона.

Answer 3

Вы можете использовать параметр / MP для проекта в целом, а затем сделать исключение для отдельного файла, используя параметр / MP1 .

Answer 4

Если вы можете ограничить количество файлов, которые вы # импортируете, вы можете поместить их в предварительно скомпилированный заголовочный файл (например, stdafx.h), который уже автоматически исключен из / MP. Это позволяет избежать упомянутой проблемы, поскольку все другие файлы будут ждать компилятора до завершения stdafx.cpp и будут все «наследовать» одни и те же определения # import.

Answer 5

Один из вариантов - переместить импорт в отдельную DLL и предоставить классы-оболочки для них с помощью непрозрачного указателя. Затем отключите / MP только для этой DLL, и остальная часть вашей сборки должна быть в порядке.

Answer 6

Вы можете разделить проект на две части: одну, которая более или менее выполняет отключение импорта / MP, и другую, которая делает все остальное, включая /MP.

.

Answer 7

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

MS говорит, что это не совместимо