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

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

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

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

Update:

Следуя совету Мэтта, он отлично работал. Для кого-то еще спотыкаясь об этом в google:

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

ОТВЕТЫ

Ответ 1

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

Ответ 2

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

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

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

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

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

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

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

Ответ 3

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

Ответ 4

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

Ответ 5

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

Ответ 6

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