Рекомендации / Опыт взаимодействия нативной библиотеки C ++ с UWP

Question

Во-первых, я знаю, что заголовок вопроса, содержащий «рекомендации», кричит о понижающих голосах и «неконструктивных» флагах, но я был бы рад, если бы вы сначала прочитали это и считали, что я сталкиваюсь конкретная проблема с точки зрения доступных учебных материалов / документации.

Банкомат Я пытаюсь расширить свое существующее приложение с Linux на Windows. Структура в основном состоит из внутреннего ядра, содержащего несколько статических нативных библиотек C ++, которые я вызываю из проекта внешнего интерфейса (C / C ++ GTK с битами других языков). ИМХО, это должен быть довольно распространенный план по расширению проекта такого рода на другие платформы с использованием библиотек core-C ++ и просто подключением их к различным платформенным интерфейсам. Теперь это будет проект UWP в этом случае.

Что меня смущает, так это кажущийся непоследовательным, прямо сейчас изменяющийся ландшафт стратегий взаимодействия с C # от Microsoft, особенно думая о C ++ / CX и C ++ / WinRT. Центральный вопрос, с которым я борюсь: Каков наилучший способ реализации собственных библиотек C ++ (в том числе путем встраивания их в виде проекта в Visual Studio для обеспечения встроенных возможностей сборки и управления зависимостями в Windows) в ваш UWP приложение? C ++ / WinRT, кажется, сильно сосредоточены на потреблении WinRT (что имеет смысл, потому что это то, чем он должен быть!). C ++ / CX кажется официально заброшенным и устарелым, и когда вы выбираете проект библиотеки Visual C ++ в VS, он автоматически ссылается на библиотеки VC ++, которые не являются родными, и я опасаюсь, что какой-то промежуточный уровень будет мешать.

Должна быть какая-то промышленная передовая практика для этого сценария, нет?

Answer 1

C ++ / WinRT и более старые расширения языка C ++ / CX - это просто способы облегчения работы с интерфейсами Windows Runtime из C ++. Одним из ключевых конструктивных значений среды выполнения Windows является упрощение написания компонента, который можно проецировать на C ++, C # и JavaScript.

Если цель вашего компонента должна использоваться всеми этими языками (что сильно влияет на дизайн интерфейса), то имеет смысл создавать интерфейсы среды выполнения Windows для вашего кода. Клиенты вашего компонента / библиотеки могут свободно использовать любой метод, который они хотят использовать для ваших типов среды выполнения Windows: взаимодействие C ++ / WinRT, C ++ / CX, C # или JavaScript.

Что касается внутренней реализации, она больше зависит от вас. C ++ / WinRT поддерживает создание компонентов среды выполнения Windows, и если вы ищете «современный C ++» способ написания API-интерфейсов среды выполнения Windows, это хороший способ, если вы начинаете с нуля. Вы также можете использовать C ++ / CX или Windows Runtime Library (WRL), хотя WRL требует определенных усилий для синхронизации генерации MDL.

Авторские API с C ++ / WinRT

Пошаговое руководство. Создание компонента среды выполнения Windows в C ++ / CX и вызов его из JavaScript или C #

Библиотека времени выполнения Windows (WRL) (канал 9)

Если, с другой стороны, вы просто пишете библиотеку C ++, которую вы ожидаете использовать в приложениях C ++ UWP, просто создайте стандартную библиотеку C ++, которую могут использовать C ++ UWP или классические настольные приложения Win32 (что я делаю, например, в Набор инструментов DirectX ). Единственные требования, которые это предъявляет к вашей библиотеке, - это придерживаться поверхности Win32 API, доступной для приложений UWP. См. эту серию блогов для различных соображений здесь. В общем, вы можете использовать только конфигурацию вашего выходящего кода.

Если вы хотите поддерживать как собственные интерфейсы C ++, так и API-интерфейсы Windows Runtime для использования в C # / JavaScript, вы можете предоставить дополнительный компонент с собственными API-интерфейсами Windows Runtime (например, Win2D для Direct2D / DirectWrite / WIC).

Небольшое историческое отступление: WRL был первым решением для использования Windows Runtime API из C ++, но было сочтено, что его слишком сложно использовать для создания интерфейсов WinRT. Внутренние разработчики Microsoft все еще использовали WRL для разработки компонентов, но обычным разработчикам рекомендовалось использовать путь C ++ / CX. См. Внутри C ++ / CX Design . C ++ / CX заимствован из существующих «зарезервированных слов» из Managed C ++, который с меньшей вероятностью конфликтует с существующим кодом, но также действительно сбивает с толку людей, знакомых с Managed C ++.

C ++ / WinRT - более современное решение, которое дает гораздо более интуитивно понятную проекцию родного языка C ++ для типов среды выполнения Windows. Эта технология в значительной степени опирается на возможности языка C ++ 14 / ++ 17, которые находились в разработке в течение некоторого времени, поэтому полностью реализовать решение C ++ / WinRT в последнее время стало возможным. Использование асинхронных API-интерфейсов Windows Runtime интуитивно понятным родным способом C ++ требует использования сопрограмм, описанных в проекте C ++ 20. В целом, C ++ / WinRT - элегантное решение, но требует передовых технологий компиляции. См C ++ / WinRT