Pourquoi le C ++ préfère-t-il toujours créer des applications à interface graphique lourde par rapport aux derniers langages dynamiques? [fermé]

Je constate que la plupart des applications à contenu graphique 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 graphiques avec les derniers langages dynamiques? Je sais que Java ne serait pas un bon choix. Mais qu'en est-il des langages comme le python qui sont nativement construits sur C? Les dernières langues ne sont-elles pas censées être meilleures que leurs ancêtres? Pourquoi devons-nous toujours préférer le vieux C ++ aux derniers langages?

Et j'aimerais aussi savoir en quoi C ++ est responsable de la meilleure vitesse de traitement de l'interface graphique? Par ailleurs, qu'est-ce qui manque aux autres dernières langues?

Je suis l'une de ces personnes qui écrivent des applications d'interface graphique C ++ (principalement pour Windows). Avec Qt, pour être précis. Mes raisons:

• J'aime le C ++. Je suis un pigiste et généralement je peux choisir mes outils (chanceux moi!)
• Dans un environnement géré, vous aurez peut-être de la difficulté à utiliser un code non géré (des déclarations WinAPI longues en C #, ça vous tente?)
• Moins de dépendances plus faciles à déployer
• Plus de contrôle sur tout.
• RAII (vs GC). Et même si j'alloue avec new, je ne fais jamais deleterien explicitement, parce que j'utilise des pointeurs intelligents ou la QObjecthiérarchie.
• Le C ++ est très excitant de nos jours, je suis impatient qu'un compilateur prenne pleinement en charge le nouveau standard.
• Rapidité (uniquement à la fin de la liste. Je sais que ce n’est pas si important pour l’interface graphique elle-même, mais il a tendance à être plus rapide car les programmes C ++ ne souffrent pas de la surcharge occasionnée par les temps d’exécution, la compilation JIT de code octet et les technologies similaires. le programme.)

Comme vous pouvez le constater, ce sont surtout des préférences personnelles. Je trouve important que mon travail soit agréable et C ++ me le fournit.

Parce que la vitesse compte.

• Les jeux utilisent le C ++ pour les tâches principales, où les performances sont importantes. Ils utilisent des langages dynamiques pour les tâches de script pour lesquelles la flexibilité est importante.

• Applications d'interface graphique de bureau : Visual Studio, par exemple, est écrit en .NET et non en C ++ natif. Cela semble fonctionner assez bien pour un IDE, car l'IDE lui-même n'a pas à effectuer 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, comme le fait remarquer wawa dans un commentaire, certains semblent l'être (par exemple, VB.NET))

• Les navigateurs doivent aussi être rapides. Après tout, ils sont en quelque sorte un système d'exploitation secondaire. D'autre part, vous pouvez affirmer que de grandes parties de Firefox sont en fait "écrites" en javascript, car la structure de Mozilla semble fortement dépendre de javascript.

Pour résumer: je ne dirais pas que le C ++ est nécessairement préféré, mais si vous avez un goulot d'étranglement, vous devez vous rapprocher du métal et ensuite vous rencontrez le C ++ (enfin, ou le C). Parfois, il sera simplement plus facile de tout faire en C ++ - un seul langage.

Les applications graphiques que vous voyez écrites en C ++ le sont généralement pour des raisons héritées. Python (avec Qt ou Gtk) est tout à fait viable pour les applications à interface graphique, tout comme C # si vous travaillez dans une maison Windows. Lorsque vous démarrez quelque chose de nouveau, l’un ou l’autre est très préféré au C ++ en raison de l’absence de travaux de plomberie.

Parce que peu importe le nombre de tests de performance. NET et les foules similaires montrent, peu importe à quel point ils se rapprochent des points de repère, l’application C ++ est finalement la meilleure. C'est plus rapide au démarrage à froid, c'est plus vif, et il y a plus de façons de l'améliorer.

Lors des phases de démarrage du projet, de nombreuses preuves ont prouvé que .NET était la voie à suivre, mais une fois choisi, il finissait toujours par devenir une lourde tâche.

De plus, C ++ est de nos jours assez sûr et facile à utiliser, en particulier avec des frameworks tels que Qt ou WTL.

La plupart des moteurs de jeu sont codés en C ++. De plus, beaucoup de moteurs de navigateur sont 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 de Source Engine, 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 d'interface graphique C ++ populaire telle que 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 C ++ vs langage dynamique, c'est mixte.

La première raison sera: habitude (ancienne)

Deuxième raison: moins de fiabilité sur les machines virtuelles, les interprètes à installer, etc.

Et il existe encore d’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 utiliser des raccourcis, optimiser le cas échéant les tâches plus intenses. Bien entendu, cela suppose que vous utilisez C ++ dans du code non managé, pas C ++ dans .NET.

Voir ici pour un exemple rapide.

C ++ est typé statiquement. Cela permet d’optimiser au préalable l’exécution de code en permettant à un compilateur d’adapter vos abstractions au processus système disponible 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 citées sont techniques ou "au-dessus de la table" ... voici des raisons commerciales ou "au-dessous de la table":

distribution du code compilé vs distribution du code source. lors du développement en c / c ++, vous distribuez les fichiers binaires. si vous développez dans l’une des langues modernes, vous distribuez la source. Il est difficile de vendre l’idée d’obfuscateurs à la direction qui doit répondre aux actionnaires / investisseurs, alors ne vous inquiétez pas.

utilisateurs stupides: du moins dans l'esprit de la direction. ils ont toujours l'impression que leurs utilisateurs ont à peine le droit de double-cliquer sur un fichier "setup.exe". Si vous incluez l'installation d'un interprète dans la configuration, ils secoueront la tête d'un côté à l'autre.

anciens développeurs: la plupart des personnes expérimentées existent depuis longtemps et ne se tiennent pas à 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 censés être concurrentiels. C ++ n'impose aucune taxe sur la plate-forme cible car il concerne la puissance de traitement, le temps d'exécution installé, les infrastructures, 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 performant, le coût de développement (potentiellement plus élevé dans le cas de C ++) est amorti par le nombre de ventes.

De plus, le C ++ offre généralement un accès direct aux apis du système (comme l'interface graphique), ce qui offre la meilleure possibilité d'optimiser l'utilisation et de se différencier des solutions similaires.

Je pense que cela a beaucoup à voir avec les API pour les toolkits GUI. Tous ont une API C / C ++, mais tous n’ont pas (par exemple) de liaisons Python. Et parfois, les boîtes à outils elles-mêmes ont été écrites avec C ++ à l'esprit. Même si elles prennent en charge d'autres langages, elles ne les prennent pas complètement en charge (par exemple, elles ne prendront pas en charge un tupleargument Python ).

Vous mentionnez les navigateurs et les jeux comme exemples. Ces deux applications sont très critiques en termes de performances. Il est donc logique de les utiliser dans un langage simple 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 ça ne se qualifie pas vraiment comme étant de haut niveau, je suppose. Mieux que C ++ cependant.)

Cependant, il existe un certain manque de cadres pour les derniers langages de programmation. Par exemple, il n’existe pas vraiment de bibliothèque d’interface graphique native viable pour Python. Bien sûr, vous pouvez utiliser PyQt ou PyGtk et ils fonctionnent bien, mais en fin de compte, il ne s’agit plus que d’une interface 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 remplacer un langage C ++ ou Java par un langage, il doit faire ce qui manque cruellement à ces langages, en plus de les exécuter à leur propre avantage. En outre, d’énormes investissements ont été investis dans ces langues. Cela signifie qu'il existe une bibliothèque standard C ++ sur de nombreuses plates-formes, que les navigateurs, les jeux et de tels programmes peuvent facilement utiliser. Il y a donc forcément une certaine inertie. Les langues ont tendance à décoller lentement contrairement aux autres logiciels.

Si vous le regardez, Anaconda (le programme d’installation de RedHat) existe depuis une dizaine d’années, écrit en Python depuis le début. Python n'était pas aussi populaire quand Anaconda était nouveau.

Google Go (golang.org) évolue très rapidement. Le compilateur n'a pas encore été démarré. Pour que sa popularité décolle, sa bibliothèque doit se stabiliser, le compilateur doit être démarré et plus de personnes doivent l’utiliser. J'ai entendu dire qu'un programme de production en dehors de Google était écrit en Go et qu'il n'aurait eu aucun temps d'arrêt dans sa vie d'un peu plus d'un an.