WinRT peut-il vraiment être utilisé uniquement aux limites?

Microsoft (principalement Herb Sutter ) recommande lors de l'utilisation de WinRT avec C ++ / CX de garder WinRT aux limites de l'application et de conserver le cœur de l'application écrit en ISO C ++ standard.

J'ai écrit une application que je voudrais laisser portable, donc ma fonctionnalité de base a été écrite en C ++ standard, et j'essaie maintenant d'écrire un frontal de style Metro pour cela en utilisant C ++ / CX. J'ai cependant eu un petit problème avec cette approche. Par exemple, si je veux pousser un vecteur de types C ++ définis par l'utilisateur vers un contrôle XAML ListView, je dois encapsuler mon type défini par l'utilisateur dans un type de référence / valeur WinRT pour qu'il soit stocké dans un Vector^. Avec cette approche, il me reste inévitablement à encapsuler une grande partie de mes classes C ++ avec des classes WinRT.

C'est la première fois que j'essaie d'écrire une application native portable en C ++. Est-il vraiment pratique de garder WinRT le long des frontières comme ça? Sinon, comment pourrait-on gérer ce type de noyau portable avec une limite spécifique à la plate-forme?

c++ portability winrt

— Bret Kuhns
source

Quelque chose comme MVVM, où Model est standard C ++, V et VM sont des objets d'interopérabilité WinRT?

— Max

"mais chaque machine virtuelle se transforme efficacement en enveloppe autour de mes modèles standard." - c'est assez courant pour les modèles de vue dans n'importe quel scénario.

— MattDavey

@ GlenH7, je crois que les commentaires ont pour la plupart répondu à cela pour moi. J'étais arrivé à la même conclusion, mais j'espérais que quelqu'un aurait une idée plus intelligente à l'esprit. En général, les choses sont comme elles sont. Vous pouvez faire de votre mieux pour isoler des parties de votre code, mais pour la plupart, vous finirez par devoir réécrire des parties du code spécifiques à la plate-forme (comme dans les exemples ViewModel ci-dessus).

— Bret Kuhns

@ GlenH7 Peut-être que la seule façon de maintenir la cohérence de votre code d'application sur toutes les plateformes est d'écrire votre propre couche d'abstraction de plateforme, mais ces couches finiront par être ce que j'essayais d'éviter en premier lieu. Il s'agit simplement de déplacer le problème avec une abstraction de couche pour isoler les choses. Peut-être que cela aide, mais à la fin, vous faites toujours le travail.

— Bret Kuhns

Nous avons essayé une fois de créer une «solution miracle» pour coller de manière transparente une bibliothèque C à Java sur Android. Enfin, cela pourrait fonctionner, après avoir passé ~ × 10 plus de temps et en utilisant des techniques de débogage exotiques (pour contourner le comportement anormal à la frontière). Certainement, c'était amusant.

— Alex Cohn

Réponses:

IMHO (ancien programmeur; travaille chez Microsoft mais ceci est une opinion personnelle): avant de pouvoir répondre à cette question, vous devez répondre à cette autre question:

Où va le code? Si vous vous en tenez à une seule plateforme (dans ce cas, WinRT), alors soyez proche de la plateforme - et cela signifie utiliser les abstractions existantes. Selon votre exemple, votre code utiliserait alors Vector ^ pour répondre aux besoins de WinRT.

OTOH, si vous vous déplacez ailleurs (VMS rock!), Alors basé sur des normes est logique.

Étant donné que les trois plus grandes plates-formes portables de type tablette du marché utilisent toutes des langages différents pour les tâches de programmation courantes, le déplacement du code pourrait ne pas être une option intéressante.

— PESMITH_MSFT
source

Je suis d'accord. J'ai commencé le projet ciblant WinRT, mais sachant qu'Android / iOS serait une plate-forme attrayante sur laquelle porter, ce qui a amené cette question. J'ai depuis décidé d'écrire spécifiquement contre WinRT uniquement. Si le projet lui-même attire une foule, je vais m'inquiéter du portage (ou plutôt de la réécriture sur une autre plate-forme).

— Bret Kuhns

Comme l'a souligné @alexcohn, si la fonctionnalité de base est suffisamment lourde au moment où je décide d'aller sur plusieurs plates-formes, cela vaudra la peine d'envelopper du code portable avec des couches spécifiques à la plate-forme. Sinon, je vais simplement réécrire le code et utiliser des suites de tests pour vérifier le comportement sur différentes plates-formes (le cas échéant).

— Bret Kuhns

Vous n'êtes pas obligé d'utiliser C ++ / CX, mais vous pouvez utiliser la WRL ( Windows Runtime Library ) qui est comme les anciens modèles ATL, pas le C ++ «semblant» qui est C ++ / CX. C'est l'approche "bas niveau" de MS à la consommation d'objets WinRT et est complètement C ++ standard comme grand-père écrivait!

Ce n'est peut-être pas aussi "agréable" que C ++ / CX mais c'est une question d'opinion - mon opinion personnelle est que C ++ / CX est la 3ème tentative d'un C ++ étendu, et est un 3ème échec. Ignorez-le et espérez qu'il va de la même manière que les 2 autres incarnations.

— gbjbaanb
source