Discussion :

[SKone]

Bonjour,

Pour répondre à la question, selon moi comme cela a été dit le C++ est encore là pour 2 raisons (selon moi), sa maturité et son historique.
Les nouveaux langages qui se présente comme les sauveurs (D, Haxe, Go...) même s'il propose d'importer des API C ce n'est pas suffisant.
Par exemple à titre personnel je travail dans les jeux vidéo, personne dans le jeux vidéo ne switch, ces langages n'ont pas de compilateur pour les consoles (Unity 3D triche ), de la même manière ceux qui font de l'embarqué ont besoin d'un compilateur pour target spécifique.
Et 90% des problèmes présentés ici de tel ou tel langage sont réglés par code. L'allocation, et bien en générale il faut recoder son propre allocateur en fonction de la plateforme (raison de perf, éviter la défragmentation mémoire, les jumps...), les RTTI sont utilisés seulement dans les parties haut niveau du code (gameplay) et souvent recoder on n'utilise pas le RTTI C++ natif, on choisit les classes dont sur lesquelles on accepte le RTTI...
Ces nouveaux langages sauveur ont les trouves cool seulement parce qu'ils sont jeunes et peu utilisés et la conséquence de ça ce n'est pas qu'ils n'ont aucun problème c'est juste qu'on n'a pas encore eu le temps de les trouver. Contrairement au C++ qui a des années de vie et des utilisations dans de très nombreux domaine. Finance (HFT...), Jeux Vidéo...
Donc on a pu le roder et fixer (ou contourner) de nombreux problèmes via des API interne.

Et aussi pour une raison historique, faire un moteur de jeu coute dans les 25 millions imaginer recoder ça dans un nouveau langage qui promet la lune non rodé => trop risqué...

Je pense que la raison historique est la première dans de nombreux domaine, ce qui explique la prédominance d'un langage de programmation dans certain domaine (C++, Cobol, JS, ...)
Indépendamment des compétences. Y a aussi une raison du marché du travail, exemple Facebook compile le PHP en C++ (Hip Hop). Il est plus facile de trouver un programmeur PHP (compétent) qu'un programmeur C++ (compétent).

Seulement moi le C++ devrait être le SEUL langage utilisé pour coder des API, simplement parce que c'est le seul langage qui permet d'être utilisé par tous. On peut facilement faire des API en C++ les exportés pour du C, du C# [PInvoke], du Fortran...
Le C++ est le langage pour les gouverner tous (pour les API). Tout est là, performance, portabilité... Tout est là c'est du Win/Win .
Ce qu'on ne peut pas faire avec du C par exemple parce qu'on perd directement la notion de classe, le thiscall ne suffit pas.
Bref sans troll aucun c'est juste un avis

[DonQuiche]

ces langages n'ont pas de compilateur pour les consoles

Avec LVVM c'est de moins en moins vrai.

Ces nouveaux langages sauveur ont les trouves cool seulement parce qu'ils sont jeunes et peu utilisés

Et parce qu'ils ont de vrais avantages et le C++ de vrais défauts.
Je veux bien reconnaître l'importance de la maturité mais pas te regarder affirmer qu'ils sont simplement "cool" parce que djeuns'.

Seulement moi le C++ devrait être le SEUL langage utilisé pour coder des API, simplement parce que c'est le seul langage qui permet d'être utilisé par tous. On peut facilement faire des API en C++ les exportés pour du C, du C# [PInvoke], du Fortran...

Non, ça c'est faux. Du code C, oui. Mais pas du code C++.

Déjà que le code C est une plaie à importer et réclame souvent une coûteuse et verbeuse gymnastique (épingler les tableaux, spécifier les offsets de chaque champ, etc), mais alors je n'imagine même pas importer du code C++, il faudrait coder des dizaines ou centaines de lignes par objet avec un type par fonction! Et je ne te parle même pas des performances désastreuses.

Ou alors il faut que ce soit du COM. Là c'est tout de suite mieux. Mais ça reste lourdingue avec des messages d'erreur parfois incompréhensibles, des problèmes de fuite mémoire à déboguer et de vieux codes d'erreur au lieu de nos exceptions. Bref, c'est lourd pour le codeur C++ et c'est lourd pour le codeur Java/C#. Et puis essaie donc d'interagir avec du code C++ depuis JS...

Enfin les API C++ sont conçues pour les objets C++. Or interagir avec vos conteneurs est une plaie sans templates. Plus généralement tous vos objets sont conçus pour le C++, tu ne peux pas prétendre que le C++ est une linga franca. Restez sur ce langage si ça vous chante mais le reste du monde a d'autres besoins et souhaite d'évoluer.

[Uther]

Seulement moi le C++ devrait être le SEUL langage utilisé pour coder des API, simplement parce que c'est le seul langage qui permet d'être utilisé par tous. On peut facilement faire des API en C++ les exportés pour du C, du C# [PInvoke], du Fortran...

Au contraire, je dirais que c'est certainement le pire langage pour cela. Le C++ n'est supporté directement par aucun langage, à part le D (qui impose quand même de très lourdes restrictions). Le C++ est bien trop complexe pour être facilement interfacable avec d'autre langage. Comme l'explique la documentation du D sur le sujet, pour s'interfacer correctement avec du C++ il faudrait que le langage réimplémente quasiment tout C++.

La seule solution pour faire du C++ interopérable consiste comme pour à peu près tous les langages de se reposer sur des wrapper en C, qui lui est une vraie lingua franca. Le problème, c'est que si on utilise réelement les capacités objet avancées de C++ ça peux très vite devenir horiblement complexe a traduire cela en C puis de les adapter aux concept équivalents du langage cible.