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?
la source
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.
la source
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.
la source