Choisir entre WPF / C # et Qt / C ++
Mon équipe et moi développons une application, qui implique un back-end écrit en C++ et implique l'utilisation de bibliothèques telles que OpenCV, MIL, etc.
Maintenant, nous devons développer une interface graphique pour interfacer avec ce programme, de telle sorte que l'interface graphique affiche les images, et l'utilisateur peut interagir avec les images et annoter/marquer les images, puis exécuter les algorithmes de traitement d'image écrits en C++ pour afficher les résultats .
Pour l'interface graphique, je suis coincé à choisir entre WPF et Qt. Personnellement, je trouve que WPF est plus facile et plus puissant que Qt. Je comprends que WPF n'est pas portable pour Linux, mais je ne m'inquiète pas trop à ce sujet ... Aussi, WPF utilise la technologie DirectX, que je devrai peut-être utiliser pour générer une visualisation 3D à un stade ultérieur.
Veuillez m'aider avec ces points:
- Puis-je interfacer WPF directement avec C++ (et pas avec Visual C # ??)
- Si (Point 1) n'est pas possible, alors considérez ceci: Le code en C++ va être gros, et impliquant également certaines bibliothèques, alors puis-je utiliser C # pour appeler des fonctions C++ Le temps investi dans l'apprentissage de Qt serait-il moindre que de faire mon un code C++ non OO non géré fonctionne avec WPF?
(J'ai l'impression que je devrais écrire trop de code pour interfacer C++ avec WPF, ce qui peut égaler la réécriture de la moitié du programme lui-même ... :-()
J'ai utilisé Qt avec C++ et WPF. Je préfère de beaucoup WPF comme cadre d'interface utilisateur. Qt n'est pas mauvais, surtout après la version 4.0. Je ne toucherais même pas aux versions antérieures de Qt.
Comme d'autres l'ont dit dans les commentaires, WPF est mieux documenté et la communauté en ligne est plus large. Si vous cherchez des applications stylisées, WPF est certainement le chemin à parcourir. Le langage déclaratif de Qt qui est nouveau est un bon pas dans cette direction, mais parce qu'il est si nouveau, il a tendance à être un peu bogué. WPF existe depuis plus longtemps et est plus mature et plus riche en fonctionnalités.
Cependant, je pense que le vrai problème dans votre cas est la base de code c ++ que vous avez.
WPF nécessitera une couche C++/CLI (C++ managé) afin de s'interfacer correctement avec votre base de code c ++. Cela semble compliqué et nécessite un peu de travail, mais ce n'est pas aussi fou que cela puisse paraître. Et il y a aussi des tonnes de documentation à ce sujet. Personnellement, je resterais loin de PInvoke.
Qt est un peu plus facile car il est basé sur c ++, mais vous aurez une traduction à faire entre les types natifs c ++ et les types Qt (comme QString, QList etc ...) qui sont utilisés en interne.
Une autre chose à considérer est le look-and-feel que vous souhaitez pour votre interface utilisateur. Par exemple, si vous envisagiez un look Nice Ribbon (office 2008, 2010), vous n'obtiendrez pas cela avec Qt. En outre, il existe une tonne de contrôles WPF tiers, mais je n'en ai pas trouvé beaucoup pour Qt. Dans certains cas, il est très pratique d'acheter un joli ensemble de contrôles pour compléter ceux que Microsoft donne par défaut.
Au cours des deux dernières années, où nous n'avons pas eu besoin d'avoir une interface utilisateur Linux, nous utilisons WPF, quelle que soit la base de code. Nous ne l'avons pas encore regretté.
Cependant, je proposerai également une troisième option. Code-jock est un cadre d'interface utilisateur basé sur MFC je crois. Il est basé sur c ++ et ActiveX. C'est devenu assez sophistiqué. Vérifiez-le ici .
EDIT: QML a parcouru un long chemin depuis que je l'ai regardé pour la première fois. Je n'ai pas eu le temps de l'examiner en profondeur, mais d'après ce que j'entends, il offre des fonctionnalités très intéressantes. Cela vaut le coup d'oeil supplémentaire.
En outre, comme quelques commentaires l'ont indiqué, il existe davantage de contrôles de type Office tels qu'un ruban, ainsi que des contrôles de diagramme et de graphique qui ont été ajoutés au jeu d'outils Qt. Cela fait de Qt une perspective intéressante.
Je maintiendrai cependant quelque chose que j'ai dit plus tôt, qu'en tant que programmeur, je trouve les interfaces utilisateur avec WPF beaucoup plus faciles, et je suis plus satisfait de mes résultats que tout ce que j'ai jamais codé avec Qt.
Si c'est C++, respectez Qt. La partie 3D de votre projet peut être gérée par le widget OpenGL de Qt. Choisir le chemin WPF vous forcera à faire certaines parties en C # ou VB.net (toujours une mauvaise pratique). Il n'y a pas beaucoup d'avantages à utiliser WPF avec C++. De plus, le reste de votre code est C/C++. convient à vos besoins. OpenCV, MIL, etc. sont un peu plus faciles à intégrer avec Qt plutôt que de faire des appels P/Invoke avec WPF (ce qui entraînera également des retards dus au marshaling .Net).
Je dirais que vous devriez vous en tenir à Qt si vous avez déjà une grande base de code C++. WPF n'est pas aussi génial et pas aussi facile à développer qu'ils le disent. C++ et Qt est une équipe bien connue, le simple C++ (pas .NET) avec WPF ne l'est pas.
WPF est un cadre d'interface utilisateur et non un langage de programmation. Vous pouvez écrire une application WPF en C # ou VB .NET. Pour utiliser du code C++ natif à partir d'une application .NET, vous avez deux options:
PInvoke - permet d'appeler l'API C simple à partir de bibliothèques natives. PInvoke ne peut pas fonctionner avec des classes C++, seulement des fonctions. Il fonctionne de la même manière que les appels d'API dans VB6.
À l'aide de l'encapsuleur C++/CLI, vous pouvez écrire une DLL .NET qui peut être utilisée par les clients C #/VB .NET. En interne, cette DLL utilise des bibliothèques natives C/C++.
Si vous vous sentez à l'aise avec WPF et n'avez pas besoin d'une solution multiplateforme, vous pouvez l'utiliser. Vous devez apprendre la partie interopérabilité. C++/CLI est un langage assez compliqué, mais un programmeur qui connaît à la fois C++ natif et .NET peut l'apprendre.
D'un autre côté, Qt permet d'utiliser directement n'importe quel code C/C++ existant et offre une solution multiplateforme.
Ces deux dernières années, j'ai utilisé SWIG pour rendre les DLL C++ pures (non gérées) disponibles dans les applications WPF. Cela fonctionne très bien, aucun problème du tout, et c'est pour les grandes applications telles que la formation en maintenance avionique.
SWIG est génial car avec un ensemble de fichiers d'interface (que vous écrivez en fonction de vos fichiers d'en-tête .h, donc assez facile), vous pouvez générer tout le code d'échafaudage pour exporter votre C++ DLL vers plusieurs langages tels que C #, Python, Lua, Java. SWIG génère le code dont vous avez besoin si vous souhaitez étendre une classe C++ à partir de C # ou Lua, il gère le passage d'exceptions entre les langages (un script Lua peut donc lancer une exception qui coule dans le C++ couche et se faire attraper au niveau C #, par exemple), etc. Nous n'avons jamais besoin de toucher PInvoke (SWIG fait tout).
De cette façon, la même interface SWIG nous a permis d'utiliser WPF (C #, avec .NET 4) pour l'interface graphique, un backend C++ natif (via SWIG) pour certaines bibliothèques existantes avec lesquelles nous devions nous intégrer et d'intégrer un interpréteur Lua pour prendre en charge les scripts de l'application (via SWIG, mêmes fichiers d'interface .i et lua-icxx sur sourceforge pour simplifier l'interfaçage avec la pile d'interpréteur de l'API Lua C).
Je me demande comment Qt/QML se compare à WPF/XAML maintenant, 2 ans après le début de ce fil. Et je vois qu'il y a maintenant Qt3D pour ajouter la 3D intégrée comme cela est disponible dans WPF depuis un certain temps maintenant (supporte nativement la toile 3D, sans OpenGL ou DirectX).
Votre code WPF devra être en C # ou VB pour obtenir le support du concepteur et de l'outillage. L'interopérabilité entre C # et C++ est très bonne via l'utilisation d'assemblages en mode mixte, qui vous permettent de coder un module en C++ qui se compile en un mélange de code managé et non managé. Cela vous donne une interopérabilité sécurisée pour vos bibliothèques C++ natives.
Voir ici pour plus d'informations sur les assemblages en mode mixte. Nous pouvons en témoigner.
Une considération importante de l'OMI est la courbe d'apprentissage du WPF. Si vous pouvez amener votre équipe avec vous, je pense que cela peut être extrêmement productif.
Dans le scénario WPF, vous ne vous connecteriez pas directement à partir de WPF (c'est-à-dire des vues xaml) directement à votre C++ non managé. Vous voudrez toujours envelopper vos modules C++ d'une sorte de wrapper géré VB ou C #. (Vous pourriez théoriquement utiliser un wrapper C++ managé, mais vous seriez fou de le faire.) WPF a besoin Modèles d'affichage minces écrits dans un langage .NET au minimum. WPF ne devrait pas avoir accès directement à votre code non managé, donc la question est plus "les applications .NET peuvent-elles s'interfacer avec C++ non managé?" et la réponse est oui, certainement .
http://msdn.Microsoft.com/en-us/library/aa984739 (v = VS.71) .aspx