Je me demande s'il y aurait un vrai impact sur le monde informatique, si les langages C/C++ venaient à disparaître. A croire qu'il n''y a aucun langage susceptible de les remplacer aujourd'hui...
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
C et C++ permettent d'avoir plus de contrôle sur le matériel
C et C++ vous permettent d'écrire du code très efficace
Les langages C et C++ sont portables
C et C++ sont des langages qui évoluent
C et C++ sont largement utilisés
C++ a peut-être de l'avenir, mais je doute que ça soit le cas de C
C a peut-être de l'avenir, mais je doute que ça soit le cas de C++
Je pense qu'ils n'ont plus beaucoup d'années devant eux
Autre (à préciser)
Pas d'avis
Discussion :
Je me demande s'il y aurait un vrai impact sur le monde informatique, si les langages C/C++ venaient à disparaître. A croire qu'il n''y a aucun langage susceptible de les remplacer aujourd'hui...
c'est la loi du marché, tant qu'il y a des programmes écrits dans ces langages, ils ne disparaîtront pas.Envoyé par zecreator
Vu la quantité de programmes, qui ne seront pas ré-écrits car trop cher à faire, ça ne risque pas même pas d'arriver demain.
Au moins dans mon domaine, la simulation numérique, je ne vois en effet pas de concurrent sérieux au C++, susceptible de le remplacer à échéance prévisible pour des applications un peu conséquentes. Dans le domaine, il n'y a que des langages plus anciens (FORTRAN), que le C++ remplace progressivement.
Pour être un concurrent sérieux à C++, un langage devrait cumuler les caractéristiques suivantes, pour un éditeur de logiciel :
a. langage mature et normalisé
b. riche bibliothèque normalisée associée au langage (ex. STL du C++)
c. indépendant d'un vendeur
d. possibilité de mixer programmation bas niveau et haut niveau
e. disponibilité de compilateurs produisant un code machine efficace
f. richesse de l'écosystème, sous la forme de bibliothèques compilables
g. bonnes perspectives de pérennité
Rien que le critère e. élimine déjà tous les langages interprétés, utilisables tout au plus pour des surcouches, IHM, etc. Ces langages ont une utilité, mais pas pour des noyaux de calcul intensifs.
Le critère f. est difficile pour des langages restés confinés à des applications de niche, même si c'est plus pour des raisons historiques que pour des limitations techniques fondamentales. Ce critère n'est pas éliminatoire, de mon point de vue, mais il faut bien évaluer les conséquences d'un tel choix dans le temps.
Il ne me viendrait pas à l'idée de démarrer le développement d'un logiciel durable sans quelques garanties sur g., qui découlent en fait des critères précédents : si je commence maintenant un gros logiciel de simulation dans un nouveau langage, écrira-t-on encore dans 20 ans des compilateurs de ce langage pour suivre les évolutions techniques des ordinateurs ?
Quand on me parle d'un langage qui ferait tant de choses mieux que C++, je me documente dessus pour le passer à travers cette série de filtres pour évaluer l'intérêt réel, dans mon cas particulier bien sûr.
Cela a été fait pour Flash, dont beaucoup de sites et contenus web ont été développés avec cette technologie. A sa disparition, la plupart ont été réécris en HTML5/Javascript. Les entreprises ont fait cet efforts d'investissement, pourquoi ne le referaient-elles pas pour des applis développées en C/C++, si cela était nécessaire ?
D'abord flash est toujours là mais ca fait maintenant quelques années que les programmes doivent migrer, et les programmes ne sont pas énormes non plus.
la masse de programmes fait en C ou C++ est sans commune mesure avec flash. Rien le fait que Unix est fait en C lui garantit une pérennité énorme.
pour le c++, les compilateurs (clang, gcc, c# etc) sont écrits avec, ainsi que tous les gros programmes (webkit etc).
donc non ce n'est pas la même chose.
Oui, ton cas semble reposé sur des projets plutôt gourmands en terme de calcul. Des projets qui semblent sortir des standards N Tiers que l'on trouvent en entreprise. en voyant tes critères, je dirai que l'on est sur du logiciel industriel, plus que de gestion et d'administration. Quel est le % de ce type d elogiciel, par rapport à l'ensemble des logiciels utilisés en entreprise ? Assez faible je pense...
En quoi la puissance du C++ peut m’être utile pour développer une application de type SIRH (centre nerveux des entreprises aujourd'hui) ? Java s'en sort très bien dans ce domaine. Mieux, avec la tendance au dématérialisé, il y a de grandes chances que la plupart de ces outils finissent par être accessibles uniquement depuis le web. Du coup, les langages web prennent de la valeur face à des monolithes comme C/C++.
Il se peut que dans l'avenir, le périmètre du C/C++ se limite à l'industrie et à la science, qui ont besoin de puissance de calcul. Pour les logiciels de gestion et d'administration en entreprise, je vois pas l'intérêt de tant de puissance... C'est un peu comme utiliser une F1 pour se promener en campagne.
Rien que les logiciels de conception mécanique (CATIA, etc.) représentent déjà des millions de licenses d'utilisation dans le monde, des PME aux grands groupes. Toutes les entreprises d'ingénierie ont des logiciels de conception et de simulation de nos jours, dans leurs domaines respectifs : électronique, thermique, mécanique des fluide, éclairage, image de synthèse, etc.
Cela ne concerne pas un commerçant qui a besoin d'un logiciel de gestion de sa compta et d'un site web de vente en ligne, évidemment, mais c'est loin d'être marginal.
Pour le reste je suis d'accord.
Il est vrai qu'il y a une espèce de dictature du C/C++, qui rappelle que rien ne fonctionnerait sans eux, et que les autres langages en sont très dépendants. Bref, c'est un peu le Bill Gates des langages quoi LOL !
Parce que tu parles avec Flash de techno front pure, qui dans le domaine du web a une espérance de vie de 2/3 ans. Alors que dans le cas de C/C++ on parle souvent de projets dont l'espérance de vie est plus 20/30 ans.
Autre facteur limitant, le changement de matériel. Je travaille sur un projet avec un total de plusieurs dizaines de millions de lignes de codes basés sur une architecture SPARK (des milliers de postes opérateurs, des dizaines de data centers). C'est simple, on se traine par contrat une solaris antédiluvienne pour des baies Sun pas beaucoup plus récentes. Sur ce genre d'archi, c'est simple, il n'y a quasiment que les compilo C/C++ qui sont toujours maintenu (et dans notre cas Java, parce que ... Bah Sun...) : Python n'a jamais dépassé la version 2.7 par exemple.
On commence à peine à envisager le portage en X86.
Autant dire qu'il faudrait vraiment un truc absolument génial et magique pour faire changer quoi que ce soit...
A la finalité, est-ce vraiment une bonne chose, d'avoir la même application maintenue depuis des décennies, qui subie des couches et sur-couches de mises à jour en fonction du hardware cible ou des tendances ? Après tant de mises à jour et d'ajouts fonctionnels, peut-on encore dire qu'il s'agit de la même application ?
Pas sûr que ces dinosaures ne finissent pas par exploser à la tête des entreprises un jour ou l'autre, malgré tous les milliers de spécialistes qui gravitent autour.
Et que se passera t-il ce jour-là, l'entreprise s'arrête ?
en fait c'est souvent quand les logiciels sont ré-écrits que les choses vont mal.
Combien d'entreprises ont été sur le tapis car ils ont perdu leur avantage le temps de la ré-écriture?
il faut lire Joel Spolsky sur le thread: Has Joel Spolsky Jumped the Shark?
ils ont préféré écrire un compilateur en deux mois plutot que de tout ré-écrire.
donc non on ne ré-écrit pas de logiciel qui ont des millions de ligne, on re-factore, on ameliore, mais on ne repart pas de zeroYour argument against Wasabi seems to boil down to the fact that it’s “beyond the pale,” “insane,” etc. These don’t sound like actual arguments to me; they’re just assertions.
FogBugz is a shrinkwrapped web app installed on customer’s own servers. It was originally written in VBScript way back when that wasn’t the worst idea in the world. Given our business constraints, spending two months writing a compiler that could preserve our code base, improve the language we used day-to-day, and continue to produce source code for our customers that runs on their platforms was the best business decision, even if it might make your head explode. Even if, as you claim, installing a PHP/.NET/Java Runtime at a customer site is everyone else’s business model, that doesn’t help us because our code is in VBScript and has been for many many years. We could port the VBScript to PHP/.NET/Java by hand, or we could spend two months writing a compiler. The latter decision took less work (a couple of months) and produced better working code that runs on all our customers’ machines without modification. I’m confident it was the best business decision, and I apologize if 50,000 programmers don’t understand it and their heads explode and 100,000 bloggers run around saying I’ve jumped the shark.
bonsoir tout le monde,
Pour ma part, je suis électronicien donc je pense que le langage C a encore de beaux jours devant lui. Je ne me vois pas (à l'heure actuelle) programmer un microcontrolleur avec un langage de plus haut niveau, j'ai bien tenté l'arduino mais je trouve que ce langage pourtant en apparence proche du "C" est catastrophique : c'est trop lent, bridé, prend trop de place etc, bref on ne maîtrise pas grand chose.. après c'est sûr cela permet à n'importe qui de mettre rapidement en oeuvre un microcontrolleur, mais les personnes qui veulent aller un peu plus loin finissent toujours par apprendre le "C" ou l'assembleur pour les plus téméraires.
Par contre, je suis toujours à la recherche d'un langage à apprendre pour enfin pouvoir développer des logiciels coté PC afin de pouvoir paramétrer mes cartes électroniques, stocker et exploiter les données des capteurs et là pour le coup je ne me voie pas faire ça en "C" ... Je pensais à la base m'orienter vers du C++ mais là j'avoue être un peu déboussolé car maintenant je me dis que apprendre l'ADA ou le pascal peut être une alternative sérieuse... Je suis venu sur ce site pour m'aider à choisir et au final j'ai plus de questions que de réponses..
C'est un très beau métier, et je suis également heureux pour toi que tu n'aies pas à utiliser C/C++. Félicitations, et je te souhaite de beaux projets!
La certification est un processus exigeant, mais qui permet de bien voir quelles sont les lacunes que l'on peut avoir dans le domaine. J'ai trouvé ce processus de certification finalement très formateur. Bien entendu, l'examen à la fin n'est pas spécialement agréable...
L'audit est un métier très intéressant, surtout dans mon cas, où j'alterne entre des projets d'audit, de consultance et de direction de projet. On est amenés à beaucoup voyager, à voir des équipes à la culture très différente dans le monde entier, de discuter de ce que l'on aime avec des professionnels du monde entier, parfois de faire du bien lorsque les rapports d'audit sont effectivement pris en compte...
Bien cordialement,
Thierryc
Version orientée-objet de la conversion de nombres [0..99] en lettres
Veuillez trouver ci-joint la version orientée-objet du projet exemple plus haut (conversion de nombre en texte, ordinaux et cardinaux). Cette version est plus complète:
- elle intègre les ordinaux et les cardinaux,
- elle intègre les langues francophones: français, québécois, belge, suisse romanche, suisse romanche Genevois,
- elle intègre l'anglais (British) et l'anglais (Americain).
L'architecture est sépare complétement l'interface utilisateur des objets métiers. Le couplage s'effectue à travers une seule unité (un module en Pascal). Le source de l'IHM est compilable et fonctionne sur Windows, Linux et MacOS sans modifications. L'interface utilisateur interroge les objets métiers pour déterminer les limites à imposer à l'utilisateur. Les différentes sécurités se complètent ainsi.
Le source des objets métiers est compilable sur toutes les plateformes cibles sans modifications et peut fonctionner aussi bien en client qu'en serveur. L'architecture des objets métiers permet d'ajouter une nouvelle langue sans aucune modification des modules existants, ni aucun changement de l'interface utilisateur.
J'en ai profité pour fournir un ensemble de cas-tests pour montrer la lisibilité des cas-tests, et la capacité qu'aurait un client non-informaticien à écrire ses propres cas-tests après une brève formation...
Bien sûr, le projet pourrait être étendu, pour viser les nombres jusqu'au milliard ou plus, et plus de langages, plus d'options, un serveur web, une version distribuée, etc.
Ci-dessous un diagramme simplifié du modèle de classes de ce projet:
Et un diagramme de paquetages:
Pour ceux qui doutent, le compilateur détecte bien A LA COMPILATION les erreurs sur les intervalles:
D'ailleurs, voici les options de vérification du compilateur:
J'en ai profité pour vérifier que le programme ne générait pas de fuites mémoire:
Pour info, l'interface utilisateur du projet:
et les résultats des tests:
L'ensemble du projet est fourni en pièce jointe. J'en profite pour remercier tous les membres de ce fil de discussion, car cela m'a permis de passer quelques heures bien agréables à faire un petit projet sympathique. N'hésitez pas à commenter. Le fichier compressé comprend également le projet en procédural d'origine, et le projet en Ada. Comme cela, vous pouvez comparer toutes les approches. Si j'ai le temps, je fournirai une dernière version, orientée-composant.
Bonne lecture...
Bien cordialement,
Thieryc
Delenda C++ est
Ton IDE n'a pas détecté un bug sérieux: Suisse romande, pas Suisse romanche
Plus sérieusement, mon OS préféré n'est pas supporté par FreePascal... d'ailleurs, rien que son noyau doit comporter une dizaine de millions de lignes de code quasi exclusivement en C plus un peu d'assembleur et il est officiellement supporté jusqu'en 2034 au moins.
On peut donc en conclure que le langage C a encore de nombreuses années devant lui
De mon point de vue, cette architecture crée trop de dépendances évitables. En particulier :
- TOutilConversionAbstrait contient trop de choses spécifiques au français. Pourtant, TOutilConversionEnglishBritish en dérive.
- Pour factoriser le code, il y a beaucoup de passages où la composition aurait pu être utilisée à la place de l'héritage. Par exemple, TOutilConversionEnglishAmerican dérive de TOutilConversionEnglishBritish, alors qu'aucun des deux types n'a de raison d'être un sous-type de l'autre.
Personnellement, en orienté objet, dans la partie métier, je n'aurais créé qu'une seule interface, avec une seule méthode virtuelle, qui convertirait un nombre en chaîne. Appelons-là ConvertisseurDeNombreEnChaine.
Dans l'interface utilisateur, quand on clique sur le bouton Convertir, cela appelle une fonction qui récupère une adresse vers un objet qui dérive de ConvertisseurDeNombreEnChaine, puis cela lit l'entier saisi, puis cela applique la conversion en chaîne, puis cela affiche la chaîne.
Ainsi, si l'interface évolue, même si on ajoute de nouveaux composants graphiques dans tous les sens pour supporter des options de plus en plus hétérogènes de plus en plus de langues, une fois qu'on a réussi à construire un objet de type ConvertisseurDeNombreEnChaine, le code qui utilise ce dernier n'a pas besoin de changer.
Ensuite, admettons que la liste des langues disponibles s'agrandisse et que, en fonction de la langue, les composants graphiques pour sélectionner les options diffèrent. Par exemple, pour le français de France, il faudrait d'une part choisir entre adjectif numéral cardinal et adjectif numéral ordinal et, d'autre part, choisir si on applique les rectifications de 1990. Dans ton exemple, il s'agit de deux boutons radio et d'une case à cocher. Par contre, pour l'espéranto, il n'y aura aucune option, donc ni bouton radio ni case à cocher. Pour l'anglais britannique, il y aura encore autre chose et ainsi de suite.
Dans ce cas, en orienté objet, dans la partie GUI, on pourrait créer une interface GuiLangue. A chaque langue correspondrait un objet dont le type dérive de GuiLangue. Cette interface aurait au moins 3 fonctions virtuelles :
- une qui sert à construire un morceau de fenêtre qui contient les composants graphiques associées aux options ;
- une qui sert à construire un objet qui dérive de ConvertisseurDeNombreEnChaine en fonction de l'état des composants graphiques associés aux options et
- une qui retourne la chaîne correspondant à la langue, par exemple "Français de France", ou un identifiant qui sera converti en chaîne en fonction de la langue de l'utilisateur, par exemple "Français de France" ou "French (France)".
Alors, dans l'interface utilisateur, quand on clique sur le bouton Convertir, cela appelle une fonction qui récupère une adresse vers un objet qui dérive de GuiLangue, en fonction de la langue sélectionnée dans l'interface. Avec cet objet, on appelle la fonction virtuelle qui permet d'obtenir un objet de type ConvertisseurDeNombreEnChaine. On utilise ce dernier sur l'entier saisi, ce qui donne une chaîne que l'on affiche.
Remarque : En C++, à la place de ConvertisseurDeNombreEnChaine, j'aurais directement utilisé le type std::function<TNombreEnChaine(TEntierBorneParle)> qui est assez similaire.
Bonjour Pyramidev,
Merci pour tes commentaires et pour avoir lu les sources si vite ;-). Cela prouve bien mon propos, ainsi que l'on peut faire de l'orienté-objet en autre chose que C++...
Il faut se souvenir que le fil de discussion est l'avenir de C++: l'exemple montre que l'on peut se dispenser de C++.
CQFD
Peux-tu être plus précis, s'il te plaît? J'ai utilisé le Français que langue de programmation, aussi le vocabulaire des opérations apparaît en français...
Ce n'est qu'une affaire de goût, comme tu l'écris toi-même. De toutes manières, toute cette partie est invisible de l'extérieur, puisqu'il n'y a qu'une interface.
C'est bien ce qui a été fait. Elle s'appelle : IOutilNombreCardinauxOrdinaux
C'est exactement ce qui a été fait:
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
4
5
6
7
8
9
permet à l'IHM de s'adapter si elle le souhaite et de ne présenter que les options valides dans ce langage.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
4
5
6
7
8function TOutilConversionEnglishBritish.GetAvailableOptions: String; begin Result:=ConstruireListeOptionsTexte( [ rsOptionAlternate, rsOptionArchaic, rsOptionArchaicFr, rsOptionCricket, rsOptionDomino, rsOptionNothingness, rsOptionInformal, rsOptionScientific, rsOptionSport, rsOptionTennis ]); end;
Concernant tes remarques sur les objets de l'IHM, tu as raison et c'est effectivement le propos de la future version orientée-composant, maintenant que la partie métier est en bonne voie. Il faut également se souvenir que différents IHM sont possibles pour Windows, Linux, MacOS, IOS et Android, ainsi qu'une IHM sur la Toile.
Au-delà de notre goût orienté-objet différent, l'exemple montre bien que le C++ est inutile et dangereux : il protège moins que le Pascal à moins de faire des contorsions imbitables avec les templates (je sais, on peut tout faire avec les templates ...) et il n'est pas lisible par les utilisateurs finaux.
Cordialement,
Thierryc
Delenda C++ est
Bonjour jlliagreTon IDE n'a pas détecté un bug sérieux: Suisse romande, pas Suisse romanche
Plus sérieusement, mon OS préféré n'est pas supporté par FreePascal... d'ailleurs, rien que son noyau doit comporter une dizaine de millions de lignes de code quasi exclusivement en C plus un peu d'assembleur et il est officiellement supporté jusqu'en 2034 au moins.
On peut donc en conclure que le langage C a encore de nombreuses années devant lui
Merci pour le rapport d'erreur, il sera pris en compte au plus tôt, dans la version orientée-composant.
Quel est ton OS, stp? N'y a-t-il que C comme compilateur disponible pour cet OS? Les applications n'y sont-elles développées qu'en C? Quels sont les autres langages disponibles?
Je reconnais bien volontiers que le C/C++/Java en legacy doit être maintenu , mais qu'on doit s'en débarasser dès que c'est économique de le faire (et c'est rapidement économique).
Cordialement,
Thierry
Delenda C++ est
pascal est mort, c'est la loi du marché. Ada est un marché de niche.
que tu le veuilles ou non, C et C++ sont la base de beaucoup de logiciels, meme de ton compilateur pascal je pense.
C++ évolue bien je trouve, le langage est devenu plus facile et plus rationnel.
le titre etait "est ce que c et c++ ont de beaux jours devant eux" la réponse est oui sans aucun doute, ne t'en deplaise.
Aussi pour te rassurer, j'ai fait du code review de Java, PLSQL et de schema db relationnel, et bien les mecs n'ont absolument pas besoin de c++ pour se tirer une balle dans le pied, déjà faudrait qu'ils apprennent la base et ensuite on en reparlera. Des langages plus simple sortent tout les jours pour que les moins bons s'en sortent malgré tout... Pendant ce temps, le c++ progresse pour que les meilleurs puissent faire leur travail correctement.
pour finir, je ne trouve pas ton code plus lisible qu'un code c++, mais ce n'est que subjectif après tout.
thierryc:
Merci, c'est intéressant, je vais voir la version Ada, étant donné que j'ai installé le compilateur.
Mais à vrai dire, personne ne doute qu'il y a des choix plus intéressants que C++ pour faire des IHM et ce type de programme, on enfonce un peu les portes ouvertes.
Et même de nombreux langages interprétés doivent faire l'affaire ici.
Ce qui m'intéresse, pour mes applications, est de savoir si ces langages sont utilisables pour faire du calcul intensif.
Sur 10 exemples de programmes de calcul ci-dessous (avec code source disponible), un programme Ada produit des exécutables de performances comparables à C++ dans 4 cas sur 10, et dans les 6 autres cas, le programme Ada équivalent est beaucoup plus lent, jusqu'à un facteur 3.
http://benchmarksgame.alioth.debian.org/u64q/ada.html
Le programme Free Pascal est presque toujours beaucoup plus lent que le même programme C++, même jusqu'à un facteur 15 sur ces exemples :
http://benchmarksgame.alioth.debian....scal&lang2=gpp
Des écarts de 20-30% ne sont pas significatifs et peuvent être attribués aux performances du compilateur, à des programmes pas écrits de façon optimale pour chaque langage, mais des écarts d'un facteur 15 sont déjà plus suspects, on se demande si cette sous-performances ne provient pas plutôt de quelque caractéristique fondamentale du langage. Mais même si ce n'était qu'une question de compilateur, ce qui m'intéresse en pratique est bien le couple (langage, compilateur disponible).
En voyant ces tests, je n'ai aucune envie d'installer et tester Free Pascal, sans intérêt pour ce que j'ai à faire, quand bien même le code serait plus lisible.
Ada part de moins loin, mais demande à être évalué rigoureusement.
Répondre avec citation
Partager