Может ли WinRT действительно использоваться только на границах?

15

Microsoft (главным образом, Херб Саттер ) рекомендует при использовании WinRT с C ++ / CX держать WinRT за границами приложения и сохранять ядро ​​приложения написанным в стандарте ISO C ++.

Я писал приложение, которое я хотел бы оставить переносимым, поэтому моя основная функциональность была написана на стандартном C ++, и сейчас я пытаюсь написать для него интерфейс в стиле Metro с использованием C ++ / CX. Однако у меня была небольшая проблема с этим подходом. Например, если я хочу передать вектор пользовательских типов C ++ в элемент управления XAML ListView, я должен обернуть мой пользовательский тип в тип ref / value WinRT, чтобы он был сохранен в Vector^. При таком подходе мне неизбежно придется обернуть большую часть моих классов C ++ классами WinRT.

Это первый раз, когда я пытался написать переносимое нативное приложение на C ++. Действительно ли практично держать WinRT вдоль таких границ? Как еще можно обрабатывать переносное ядро ​​такого типа с определенной платформой границей?

Брет Кунс
источник
Что-то вроде MVVM, где Model - это стандартные C ++, V и VM - объекты взаимодействия WinRT?
Макс
5
«но каждая виртуальная машина фактически превращается в обертку вокруг моих стандартных моделей». - это довольно распространено для просмотра моделей в любом сценарии.
MattDavey
1
@ GlenH7, я думаю, что комментарии в основном ответили на это для меня. Я пришел к такому же выводу, но надеялся, что у кого-то была более умная идея. В общем, все так, как есть. Вы можете сделать все возможное, чтобы изолировать части вашего кода, но по большей части вам придется переписывать специфичные для платформы части кода (как в примерах ViewModel выше).
Брет Кунс
1
@ GlenH7 Возможно, единственный способ сохранить согласованность кода вашего приложения на разных платформах - это написать собственный уровень абстракции платформы, но эти уровни в конечном итоге станут тем, чего я пытался избежать в первую очередь. Это просто перемещает проблему с помощью абстракции слоя, чтобы изолировать вещи. Возможно, помогает, но в конце концов вы все еще делаете работу.
Брет Кунс
1
Однажды мы попытались создать «серебряную пулю», чтобы легко склеить библиотеку C с Java на Android. Наконец, это может сработать, потратив ~ 10 раз больше времени и используя экзотические методы отладки (чтобы обойти ненормальное поведение на границе). Это было весело.
Алекс Кон

Ответы:

8

ИМХО (старый программист; работаю в Microsoft, но это личное мнение): прежде чем я смогу ответить на этот вопрос, вы должны ответить на этот другой вопрос:

Куда движется код? Если вы придерживаетесь одной платформы (в данном случае WinRT), тогда будьте ближе к платформе - а это означает использование существующих абстракций. Согласно вашему примеру, ваш код будет использовать Vector ^ для соответствия потребностям WinRT.

OTOH, если вы переезжаете куда-то еще (VMS качается!), То основанные на стандартах имеет смысл.

Принимая во внимание, что все три крупнейшие портативные платформы, подобные планшетам на рынке, используют разные языки для выполнения общих задач программирования, перемещение кода может быть не очень полезным вариантом.

PESMITH_MSFT
источник
Я согласен. Я начал проект, нацеленный на WinRT, но зная, что Android / iOS будет привлекательной платформой для портирования, что вызвало этот вопрос. С тех пор я решил написать специально против WinRT. Если сам проект соберет толпу, я буду беспокоиться о портировании (или, скорее, о переписывании на другую платформу).
Брет Кюнс
Как отметил @alexcohn, если основные функциональные возможности будут достаточно тяжелыми в то время, когда я решу перейти на кросс-платформенный режим, то будет полезно обернуть переносимый код уровнями, специфичными для платформы. В противном случае я просто переписываю код и использую наборы тестов для проверки поведения на разных платформах (где это уместно).
Брет Кюнс
0

Вам не нужно использовать C ++ / CX, вместо этого вы можете использовать WRL ( Windows Runtime Library ), которая похожа на старые шаблоны ATL, а не на «притворный» C ++, который является C ++ / CX. Это «низкоуровневый» подход от MS к потреблению объектов WinRT, и он полностью стандартный C ++, как когда-то писал дедушка!

Это может быть не так "приятно", как C ++ / CX, но это вопрос моего мнения - лично я считаю, что C ++ / CX - это третья попытка расширенного C ++ и третья ошибка. Не обращайте на это внимания и надеюсь, что это пойдет так же, как и в двух других воплощениях.

gbjbaanb
источник