Microsoft (главным образом, Херб Саттер ) рекомендует при использовании WinRT с C ++ / CX держать WinRT за границами приложения и сохранять ядро приложения написанным в стандарте ISO C ++.
Я писал приложение, которое я хотел бы оставить переносимым, поэтому моя основная функциональность была написана на стандартном C ++, и сейчас я пытаюсь написать для него интерфейс в стиле Metro с использованием C ++ / CX. Однако у меня была небольшая проблема с этим подходом. Например, если я хочу передать вектор пользовательских типов C ++ в элемент управления XAML ListView, я должен обернуть мой пользовательский тип в тип ref / value WinRT, чтобы он был сохранен в Vector^
. При таком подходе мне неизбежно придется обернуть большую часть моих классов C ++ классами WinRT.
Это первый раз, когда я пытался написать переносимое нативное приложение на C ++. Действительно ли практично держать WinRT вдоль таких границ? Как еще можно обрабатывать переносное ядро такого типа с определенной платформой границей?
источник
Ответы:
ИМХО (старый программист; работаю в Microsoft, но это личное мнение): прежде чем я смогу ответить на этот вопрос, вы должны ответить на этот другой вопрос:
Куда движется код? Если вы придерживаетесь одной платформы (в данном случае WinRT), тогда будьте ближе к платформе - а это означает использование существующих абстракций. Согласно вашему примеру, ваш код будет использовать Vector ^ для соответствия потребностям WinRT.
OTOH, если вы переезжаете куда-то еще (VMS качается!), То основанные на стандартах имеет смысл.
Принимая во внимание, что все три крупнейшие портативные платформы, подобные планшетам на рынке, используют разные языки для выполнения общих задач программирования, перемещение кода может быть не очень полезным вариантом.
источник
Вам не нужно использовать C ++ / CX, вместо этого вы можете использовать WRL ( Windows Runtime Library ), которая похожа на старые шаблоны ATL, а не на «притворный» C ++, который является C ++ / CX. Это «низкоуровневый» подход от MS к потреблению объектов WinRT, и он полностью стандартный C ++, как когда-то писал дедушка!
Это может быть не так "приятно", как C ++ / CX, но это вопрос моего мнения - лично я считаю, что C ++ / CX - это третья попытка расширенного C ++ и третья ошибка. Не обращайте на это внимания и надеюсь, что это пойдет так же, как и в двух других воплощениях.
источник