Pourquoi C ++ est-il toujours préférable de créer des applications GUI lourdes sur les derniers langages dynamiques?
Je vois que la plupart des applications qui incluent un contenu GUI lourd sont généralement développées en C++. La plupart des jeux/navigateurs sont codés en C++.
Ne pouvons-nous pas simplement développer de meilleures applications GUI avec les dernières langues dynamiques? Je sais Java ne serait pas un excellent choix. Mais qu'en est-il des langages comme python qui sont nativement construits sur C? Les derniers langages ne sont-ils pas censés être mieux que leurs ancêtres? Pourquoi devons-nous encore préférer l'ancien C++ aux dernières langues?
Et je voudrais aussi savoir, qu'est-ce qui est responsable en C++, pour la meilleure vitesse de traitement GUI? Par contre qu'est-ce qui manque aux autres dernières langues?
Je fais partie de ces personnes qui écrivent des applications GUI C++ (principalement pour Windows). Avec Qt, pour être précis. Mes raisons:
- J'aime C++. Je suis pigiste et je peux généralement choisir mes outils (chanceux!)
- Dans un environnement géré, vous pouvez avoir du mal à utiliser du code non managé (déclarations WinAPI de longue haleine en C #, n'importe qui?)
- Moins de dépendances plus faciles à déployer
- Plus de contrôle sur tout.
- RAII (par rapport à GC). Et même si j'alloue avec
new, j'ai rarementdeletequoi que ce soit explicitement, car j'utilise des pointeurs intelligents ou la hiérarchieQObject. - C++ est très excitant ces jours-ci, j'ai hâte qu'un compilateur supporte pleinement la nouvelle norme.
- Vitesse (uniquement à la fin de la liste. Je sais que ce n'est pas si important pour l'interface graphique elle-même, mais elle a tendance à être plus rapide car les programmes C++ ne font pas ' t souffrent de la surcharge que les temps d’exécution, la compilation de code JIT et les technologies similaires ajoutent au programme.)
Comme vous pouvez le voir, ce sont principalement des préférences personnelles. Je trouve important que mon travail soit agréable et C++ me le fournit.
Parce que la vitesse compte.
Jeux utilisez C++ pour les tâches principales, où les performances sont importantes. Ils utilisent des langages dynamiques pour les tâches de script où la flexibilité est importante.
applications GUI de burea: Visual Studio, par exemple, est écrit en .NET et non en C++ natif. Il semble fonctionner assez bien pour un IDE, car le IDE lui-même n'a pas besoin de faire beaucoup de tâches exigeantes en performances. (Le compilateur, l'éditeur de liens et d'autres outils ne sont pas nécessairement écrits en .NET - bien que wawa le souligne dans un commentaire, certains semblent l'être (par exemple VB.NET))
Navigateurs doivent également être rapides. Après tout, ils sont une sorte de système d'exploitation secondaire. D'un autre côté, vous pouvez affirmer que de grandes parties de Firefox sont en fait "écrites" en javascript, car le framework Mozilla semble dépendre fortement de javascript.
Pour résumer: je ne dirais pas que C++ est nécessairement préféré mais si vous avez un goulot d'étranglement en termes de performances, vous devez vous rapprocher du métal et ensuite vous rencontrez C++ (enfin, ou C). Parfois, il sera plus facile de tout faire en C++ - un langage.
Les applications GUI que vous voyez écrites en C++ le sont généralement pour des raisons héritées. Python (avec Qt ou Gtk) est très viable pour les applications GUI, tout comme C # si vous travaillez dans une maison Windows. Lorsque vous démarrez quelque chose de nouveau, c'est très beaucoup préféré au C++ en raison du manque de travaux de plomberie qui doit être fait.
Parce que peu importe le nombre de tests de performances .NET et les foules similaires montrent, peu importe à quel point ils se rapprochent des repères, à la fin, l'application C++ arrive en tête. Il est plus rapide au démarrage à froid, plus rapide et a plus de façons de l'améliorer.
J'ai entendu de nombreuses preuves lors des phases de démarrage du projet que .NET est la voie à suivre, mais une fois choisi, ils ont toujours été un lourd fardeau.
De plus, C++ de nos jours est assez sûr et assez facile à utiliser, en particulier avec des frameworks comme Qt ou WTL.
La plupart des moteurs de jeux sont codés en C++. De nombreux moteurs de navigateur sont également codés en C++. Mais l'interface graphique du navigateur est souvent codée à l'aide d'un script léger (JavaScript, Python). À l'exception notable du moteur source, la plupart des moteurs de jeux utilisent également des langages de script (comme Lua ou Python). [pour référence: liste des jeux scriptés Lua ]
Prenez également la bibliothèque GUI C++ populaire comme Qt. Dans la version actuelle (4.7), il utilise QML pour l'interface graphique. QML est essentiellement JavaScript avec des liaisons Qt.
Donc vraiment il n'y a pas de langage dynamique C++ vs, c'est mélangé.
La première raison sera: (ancienne) habitude
Deuxième raison: moins de fiabilité sur les machines virtuelles, les interprètes à installer, etc.
Et il existe encore quelques excellents IDE pour développer du code en C++.
La raison en est que vous avez beaucoup plus de contrôle sur tout ce qui se passe. Si vous deviez écrire photoshop en C #, vous auriez de sérieux problèmes de performances pour certaines tâches. Dans un langage de niveau inférieur avec plus de contrôle, vous pouvez prendre des raccourcis, optimiser là où c'est nécessaire pour des choses plus intenses. Bien sûr, cela suppose que vous utilisez C++ dans du code non managé, et non C++ dans .NET.
Voir ici pour un exemple rapide.
C++ est typé statiquement. Cela permet d'optimiser au préalable l'exécution du code en faisant en sorte qu'un compilateur adapte vos abstractions aux processus système disponibles sur une plate-forme donnée. Jusqu'à présent, les langages dynamiques ont besoin d'une couche logicielle supplémentaire (= l'interpréteur) qui ralentit l'accès aux ressources système.
La plupart des raisons invoquées sont d'ordre technique ou "au-dessus du tableau" ... voici des raisons commerciales ou "sous le tableau":
distribuer du code compilé vs. distribuer le code source. lors du développement en c/c ++ vous distribuez les binaires. si vous développez dans l'une des langues modernes, vous distribuez la source. il est difficile de vendre l'idée d'obscurcisseurs à la direction qui doit répondre aux actionnaires/investisseurs, alors ne vous embêtez pas.
utilisateurs stupides: au moins dans l'esprit de la direction. ils perçoivent toujours leurs utilisateurs comme étant à peine capables de double-cliquer sur un "setup.exe". Si vous incluez l'installation d'un interprète dans le cadre de la configuration, ils secoueront la tête d'un côté à l'autre.
anciens développeurs: la plupart des gens expérimentés existent depuis longtemps et ne se sont pas tenus à jour. ils programment en C++ et non dans les nouveaux langages, car ils ne connaissent pas les nouveaux langages.
Je voudrais étendre la portée du problème de l'interface graphique aux logiciels qui devraient être compétitifs. Le C++ n'impose aucune taxe sur la plate-forme cible en ce qui concerne la puissance de traitement, le temps d'exécution installé, les frameworks, etc. Il fonctionnera donc sur un matériel client plus limité qu'une solution similaire écrite dans un langage géré/interprété. Dans le cas d'un logiciel commercial réussi, le coût de développement (potentiellement plus élevé dans le cas du C++) est amorti par le nombre de ventes.
De plus, C++ offre généralement un accès direct aux API du système (comme l'interface graphique), ce qui donne la meilleure opportunité d'optimiser l'utilisation et de se différencier des solutions similaires.
Je pense que cela a beaucoup à voir avec les API pour les boîtes à outils GUI. Tous ont une API C/C++, mais tous n'ont pas (disons) Python. Et parfois les boîtes à outils elles-mêmes ont été écrites avec C++ à l'esprit, donc même si elles ont un support pour les autres langages, ils ne les prennent pas complètement en charge (par exemple, ils ne prendront pas en charge un Python Tuple comme argument).
Vous citez des navigateurs et des jeux comme exemples. Ces deux applications sont assez critiques pour les performances, il est donc logique de les avoir dans un langage de bas niveau pour la vitesse.
De nombreuses autres applications sont moins liées aux performances et pourraient facilement être écrites dans d'autres langues. C # en particulier semble être beaucoup utilisé. (Et Obj-C, mais il n'est pas vraiment qualifié de haut niveau, je suppose. Mieux que C++ cependant.)
Cependant, il existe un certain manque de frameworks pour les derniers langages de programmation. Par exemple, il n'y a pas vraiment de bibliothèque GUI native viable pour Python. Bien sûr, vous pouvez utiliser PyQt ou PyGtk et ils fonctionnent bien, mais au final, cela ne fait qu'interfacer avec le code C. Encore une fois, C # (et sans doute Obj-C) semble être l'exception et peut-être que MacRuby ou IronPython pourraient changer ce jeu.
Pour qu'un langage remplace C++ ou Java, il doit faire ce qui est cruellement manqué dans ces langages en plus de les exécuter à leurs propres forces. De plus, d'énormes investissements ont été consacrés à ces langues. Cela signifie qu'il existe une bibliothèque C++ standard sur de nombreuses plates-formes, que les navigateurs, les jeux et ces programmes peuvent facilement utiliser. Il y a donc forcément une certaine inertie. Les langues ont tendance à décoller lentement contrairement à d'autres logiciels.
Si vous le regardez, Anaconda (le programme d'installation de RedHat) existe depuis environ 10 ans, écrit en Python depuis le début. Python n'était pas ce populaire quand Anaconda était nouveau.
Google's Go (golang.org) évolue très rapidement. Le compilateur n'a pas encore été amorcé. Pour que sa popularité décolle, sa bibliothèque doit se stabiliser, le compilateur doit être démarré et plus de gens doivent l'utiliser. J'ai entendu dire qu'un programme de production en dehors de Google est écrit en Go et n'aurait pas encore eu de temps d'arrêt dans sa vie d'un peu plus d'un an.