C # vs C++ dans un projet multi-plateforme
Mon équipe prévoit de développer une application initialement ciblée Pour Windows mais qui sera éventuellement déployée multiplateforme (Mac, Linux et périphériques potentiellement embarqués). Notre décision est d'utiliser C#/. NET ou c++ générique (avec Qt comme bibliothèque d'interface utilisateur). Nous prévoyons qu'en utilisant C#, nous pouvons développer notre produit plus rapidement et à moindre coût en raison de l'augmentation de la productivité sur C++, mais nous prenons un pari sur la question de savoir si les implémentations multiplateformes de C # seront être assez mature au moment où nous voulons déployer à d'autres plates-formes.
Des suggestions de l'un d'entre vous qui ont été dans une situation similaire?
18 réponses
Malgré toutes les capacités multiplateformes potentielles de Mono, aujourd'hui, C++/Qt est simplement une option beaucoup plus mature que C#/WinForms ou C#/Gtk# à des fins multiplateformes. Tous les gains de productivité que vous obtiendriez en utilisant un langage de plus haut niveau seraient probablement compensés par les limitations de Mono.
Jen, Je m'inquiète du libellé de votre question.
" mon équipe prévoit de développer une application initialement ciblée Pour Windows mais qui sera éventuellement déployée multiplateforme (Mac, Linux et périphériques potentiellement embarqués)."
Est le plan de faire multi-plateforme ou non? Je peux déduire que le code sera initialement écrit Pour Windows, puis, peut-être un peu plus tard, des efforts seront déployés pour modifier le projet pour une capacité multiplateforme. Ce ne sera pas bon pour votre santé ou celle de votre équipe! Une décision d'affaires définitive doit être prise ici. L'une des règles d'or du développement multiplateforme est de traiter toutes les plates-formes ciblées avec une égalité absolue.
Pouvez-vous utiliser C# pour les environnements embarqués? Cela a-t-il déjà été fait commercialement? Juste curieux.
" nous prévoyons qu'en utilisant C#, nous pouvons développer notre produit plus rapidement et à moindre coût grâce à L'augmentation de la productivité par rapport au C++" Que voulez-vous dire 'projeter'? Sur ce faits et chiffres faites - vous cette projection? N'oubliez pas que l'effort de codage sur certains projets est faible comme ~20% de l'effort total requis pour mettre un produit sur le marché. Ainsi, la question de la comparaison de la productivité des langages informatiques peut ne pas être si importante. Selon mon expérience, il n'est pas productif de choisir un langage informatique sur les critères de productivité.
"nous prenons un pari" je suis d'accord avec cela, et le jeu semble contredire le sens de la planification. Le la question est: quels sont les risques?
Avez-vous envisagé l'internationalisation?
Oui, je suis critique, mais quelqu'un qui paie l'argent pour ce projet pourrait bien être plus questionné.
Livre: Développement multiplateforme en C++: création D'Applications MAC OS X, Linux et Windows par Syd Logan-ISBN 032124642X Donne une idée des enjeux.
J'ai été sur un projet multiplateforme et internationalisé Pour Windows, Mac et Linux en utilisant C++ / Qt. Le ce dernier fait bien pour les deux questions. Un dis-like que J'ai de Qt est que ce N'est pas c++ moderne dans l'idiome et qu'il n'encourage pas l'utilisation d'idiomes c++ modernes. Tout comme les MFC.
Je développe depuis des années des logiciels multi-plateformes avec C++ / Qt.
Je recommande fortement cette solution pour votre développement.
Une telle solution vous apporte des performances sur toutes les plates-formes!
De plus, Qt n'est pas seulement un framework GUI, mais vous apporte un framework complet pour la mise en réseau, la base de données, les E / S, un excellent support et un système d'internationalisation très ingénieux !
Enfin, Qt fournit une recherche native sur toutes les plates-formes qu'il prend en charge.
Et sur la performance, est Mono / C # équivalent à C++ / Qt ?
Encore une question où la réponse est: Ça dépend! (Compétence de vos programmeurs en C# et c++ et s'ils sont vraiment beaucoup plus rapides en C# et ainsi de suite).
Juste une remarque:
le projet Mono fournit une plate-forme (version 2.0 prend en charge JUSQU'à.Net 3.0) qui peut être utilisé sur les systèmes Mac ou Linux. Y compris le sucre de code microsoft comme LINQ.
L'approche que j'ai adoptée avec de nombreux projets multiplateformes consiste à écrire le "noyau" du projet dans un langage très portable (C++), puis à implémenter L'interface utilisateur (et tout ce qui dépend du système D'exploitation, par exemple certains types d'accès aux données) dans un langage efficace pour cette tâche sur les différentes plates-formes.
Je voulais juste souligner que vous n'êtes pas coincé avec le choix d'une seule langue.
Êtes-vous configuré pour n'avoir qu'un seul ensemble de code D'interface utilisateur sur toutes les plates-formes? Je vous encourage à considérer deux interfaces utilisateur séparées avec un noyau commun, il n'y a vraiment pas de substitut à une interface utilisateur native.
Dans ce cas, vous pouvez aller Winforms / WPF en C# pour L'interface utilisateur Windows, Cocoa en ObjC pour L'interface utilisateur OS X, GTK en C# Pour L'interface utilisateur Linux. Tous ces éléments utiliseraient un noyau c# commun capable de fonctionner sur Mono et .NET. Mono le rend relativement indolore à utiliser avec ObjC.
Si vous voulez aller multi-plateforme, C++ est certainement le chemin à parcourir.
Modifier: Je pense que vous devriez choisir votre langue en fonction de votre projet, et ne pas préférer une langue parce que vous y êtes simplement habitué. Bien que C# puisse offrir un support multi-plateforme, il a été initialement conçu pour fonctionner uniquement sur Windows.
Mark Maslar a un bon point aussi, selon l'application que vous souhaitez développer, une application web serait complètement indépendante de la plate-forme.
Potentiellement quels périphériques embarqués? S'ils ne fonctionnent pas avec. net ou Mono, vous couperez la possibilité si vous allez avec C#. (Il ne doit pas nécessairement s'agir d'un problème de système d'exploitation; certains périphériques embarqués ont des limites de mémoire ou de performance strictes, que.NET/Mono peut dépasser.)
Si ce n'est pas critique, il y a beaucoup de facteurs à considérer. Est-ce que votre projet utilise ce qui serait des fonctionnalités. net standard, ou Êtes-vous susceptible de forcer Mono? Est-ce un cas de connaître C# et non C++, ou avez-vous juste avoir une meilleure expérience avec C#? (Si vous êtes meilleur avec C++ que C#, alors C# n'est pas susceptible de donner des avantages de productivité sur un projet, et vous devriez simplement aller C++ et obtenir de l'expérience C# sur quelque chose de moins multi-plateforme.) Quelle est l'importance d'obtenir une version rapide sur Windows? (Il pourrait être vital d'obtenir un avantage de premier mover, ou mineur si vous faites quelque chose de moins critique dans le temps.) Combien allez-vous bénéficier des versions Mac et Linux (généralement plus que leur part de marché indiquer, car il y a moins de concurrence)?
Mon intuition ici serait d'aller de l'avant et de se développer pleinement en C#. Si et quand vous rencontrez des problèmes de compatibilité croisée, réécrivez les sections nécessaires dans les DLL C / C++ / bibliothèques partagées. apparemment, Mono peut en effet Gérer les bibliothèques partagées sur une base spécifique à la plate-forme.
En fonction de ce que vous faites, cela pourrait finir par être totalement déraisonnable, mais vous auriez toujours la possibilité de garder le développement rapide de Windows, et vous n'auriez à réécrire que des parties de l'application en C++, pas l'ensemble de la chose.
Avez-vous envisagé d'utiliser python/C++/QT ?
Il suffit de regarder
Juste pour ajouter avec cette discussion. J'ai développé un logiciel en c++. Je suis le seul développeur et sa finition 80%.
Maintenant, je trouve difficile d'obtenir un programmeur C++ et aussi un programmeur PHP expérimenté. Geting beaucoup de programmeur c#.
Je connais aussi c#. Il peut prendre un mois deux convertir c++ en c# (laissant certaines fonctionnalités que je me sens trop à maintenir).
Mon aversion est la taille. net. J'ai regardé mono ainsi. Personnellement, c'est pas un problème pour moi, car je suis très bon en C++. Mais geting programmeur qui peut faire un projet complexe de bits avec PHP est devenu difficile. Ils sont juste développeur web de base( l'endroit que je cherche programmeur et mon budget).
Personnellement, j'aime c++ et aime la petite taille de l'exécutable. Mon pririty est à vendre en ligne. D'autre part, c'est un programme serveur donc besoin d'une instance dans un réseau local.
Je dois prendre une décision par mois car je dois commencer à terminer ce projet.
Vous pouvez regarder mon type de projet sur ashnah dot com
Si vous êtes engagé dans une approche multi-plateforme, je pense que cela dépend de la lourdeur de L'interface utilisateur de votre application. Si la viande de l'application est dans le back-end, une possibilité non mentionnée est d'opter pour un mélange de C++ et C++/CLI. C++ / CLI vous donne accès à la vaste BCL. NET (y compris les composants de L'interface utilisateur) afin que vous puissiez accéder rapidement au marché sur Windows, et vous pouvez vous en tenir à vanilla C++ où cela n'est pas nécessaire. Ensuite, pour porter vers une autre plate-forme, il vous suffit de cibler les parties C++/CLI.
Sur d'autre part, vous voulez sérieusement remettre en question la partie "éventuellement" du plan de migration vers d'autres plates-formes. Se concentrer exclusivement sur Windows et utiliser. net avec C# ou VB.NET vous donne un itinéraire de développement plus facile en termes de compétence de programmeur dont vous aurez besoin.
Pourquoi ne pas utiliser plusieurs langues. Utilisez C++ pour le framework sous-jacent qui sera le noyau (le plus de travail nécessaire ) de votre application et de votre plate-forme indépendante. Ensuite, vous pouvez créer L'interface utilisateur en C# pour votre version Windows, et si plus tard vous décidez de porter sur Mac ou autre chose, vous pouvez l'écrire en Java ou Qt ou quelle que soit la langue/API que vous décidez d'utiliser. Je pense que c'est ok si l'interface utilisateur dépend de la plate-forme tant que le noyau de votre application ne l'est pas.
, Il serait préférable de décidez tout de suite si votre application sera multi-plateforme, mais si vous ne le pouvez pas, je pense qu'une interface utilisateur dépendante de la plate-forme avec un framework/infrastructure indépendant de la plate-forme est un bon moyen d'aller.
On dirait que vous essayez de créer des applications client fat multiplateformes avec des variantes C. vous devriez totalement laisser tomber cela et utiliser jQuery.
Non, sérieusement, fonctionnalités html5 peut faire face à vos connectivité intermittente, et vous obtenez bon IU, non seulement sur Win/Mac/Linux, mais sur plates-formes mobiles et tout et tout.
Allez, avec les années 90! Ce n'est pas si dur ou mauvais et vous obtenez d'être tout béat quand les gens disent "nuage".
Prenez Java / Scala en considération. L'un des plus merveilleux développeur IDEs IntelliJ IDEA est écrit en Java-jetez un oeil.
Je n'ai aucune expérience dans ce scénario, donc ça vaut ce que ça vaut... J'utiliserais probablement. Net, mais je ciblerais toujours Mono. Cela signifierait un risque beaucoup moins élevé d'utiliser L'implémentation MS de. Net et de devenir dépendant par inadvertance de certaines fonctionnalités encore non implémentées dans Mono, détruisant ainsi votre portabilité vers des plates-formes autres que Windows.
Si cela ne vous dérange pas le look non-natif dans Windows (ce qui est évident même avec le skin" windows " utilisé par GIMP), vous pouvez utiliser Gtk# et Mono. En ce qui concerne les choses de L'interface utilisateur, J'ai trouvé Gtk# plus facile et plus intuitif (à partir d'un POV de programmation) que le framework.net. D'un autre côté, le débogage sera probablement plus facile si vous utilisez .NET.