Discussion :

[Ptibibi]

Pour moi le C++ c'est un langage batard qui a les inconvénients du C sans profiter de ses avantages et passe a coté de l'interet de la programmation orientée objet, a savoir la programmation de haut niveau.

Tu vas faire hurler plus d'un programmeur en proclamant ça ! Moi y compris. Pourtant, j'apprécie tout autant la programmation JAVA que C++.

Petite question, connais-tu ton sujet ? Parce-que là franchement. Soit tu n'y connais rien, soit tu es un pro-javaiste qui a décidé de prendre en grippe le C++ et qui ne cherche pas plus loin que le bout de son clavier.

[feed_our_vision]

je dois dire que coté performance le C++ tue le c# et le java et question fonctionnalite il apporte la meme chose cependant en terme de portabilite de code et de ligne de code la il est totalement dépassé

je ne suis d'accord quand tu parles de perfomances mais en ce qui concerne le fait qu'il soit depassé,on aurait vraiment du mal a faire certaines choses avec C# et JAVA.
Alors il ne serait jamais depassé.comme si on pouvait se passer de asm

[kaisse]

Pour moi le C++ c'est un langage batard qui a les inconvénients du C sans profiter de ses avantages et passe a coté de l'interet de la programmation orientée objet, a savoir la programmation de haut niveau.

Tu vas faire hurler plus d'un programmeur en proclamant ça ! Moi y compris. Pourtant, j'apprécie tout autant la programmation JAVA que C++.

Petite question, connais-tu ton sujet ? Parce-que là franchement. Soit tu n'y connais rien, soit tu es un pro-javaiste qui a décidé de prendre en grippe le C++ et qui ne cherche pas plus loin que le bout de son clavier.

Ouïe, je suis même impressioné qu'il n'y ait eu qu'une réaction pour l'instant . Je vais revenir sur ce qu'à dit mije. En fait, je suis d'accord sur l'idée que c'est un langage batard, même si je ne suis pas trop d'accord pour le terme qui est trop péjoratif à mon gout.
Je maitrise trois langages: C, C++ et Java. J'ai fait le compte des projets et autres petits programmes que j'ai développés cette année et je me suis rendu compte que je n'ai pas fait un seul projet de taille moyenne ou grande en C++ (le plus gros que j'ai fait contient deux headers et trois fichiers cpp). Je me suis alors demandé pouquoi ?

J'ai beaucoup utilisé le C pour faire des utilitaires de traitements de fichiers et de données basiques, mais aussi pour implémenter des algorithmes de chiffrement. On veut que ces taches soient efficaces, rapides. De plus, elle ne nécessite pas de grande abstraction. J'ai donc naturellement utiliser le C.

J'ai aussi du programmer deux projets assez costauds, un pour la fac et un pour un stage. Il fallait une belle GUI, quelque chose d'extensible de portable et de tout chouette. Pour toutes ces raisons, et aussi parce que un garbage collector ça aide !, j'ai développé ces deux "grosses" applis en Java.

Mais alors avec quelles applications serait-il judicieux de programmer en C++ ? Et bien justement, celles qui regroupent ces deux exigences: quelque chose de portable, extensible, réutilisable, bref un gros projet, mais avec des exigences particulière sur la rapidité, l'efficacité, l'espace mémoire occupé. Je pense que les grosses applications scientifiques, nécessitant de gros calculs (par exemple les simulations de systèmes physiques-météorologique etc...) doivent être friandes de C++.

Et puis pour tout avouer, il y a aussi le fait que le C++ ne se maitrise pas comme ça. J'ai mis environ un an à bien maitriser le Java. Non que c'était difficile, mais j'apprenais en même temps la programmation, et au départ, ne connaissant pas le domaine, je n'étais pas passioné par l'informatique. Quant au C, j'ai vraiment mis 5 mois à bien le maitriser, et même si au départ, ca me parraissait moins touffu que le java (du fait de l'API), il s'est révélé que ce langage était plus fin, plus difficile à maitriser.

Et bien le C++ justement est encore plus difficile à assimiler. Du fait de son aspect objet, il demande une grande abstraction, mais demande encore beaucoup de connaissances techniques, puisque le système d'allocation-desallocation de mémoire est toujours utilisé. Aprés un an de pratique, je trouve encore que mon code est innaproprié quand je programme en C++. Soit je bidouille comme du C, soit je fait du copier-coller de Java et je déclare des class à tort et à travers. Sans parler de la déclaration de classes ou de fonctions templates ...

En résumé, d'aprés mon expérience, le C++ est un langage qui demande beaucoup de maturité de la part du programmeur. Aussi, quand les entreprises développent des applis, si elles peuvent se passer du C++ pour utiliser un autre langage elles le feront. C'est pourquoi, à mon humble avis, le C++ est relativement peu utilisé par rapport à d'autres langages comme le Java, mais par contre, les domaines qui l'utilisent ne sont pas prêts de changer de langage.

[Yabo]

Quant au C, j'ai vraiment mis 5 mois à bien le maitriser

5 mois ? Ca fait 3 ans et demi que je fais du C et je ne dirais pas que je le maîtrise à 60 voir 70%. Et pourtant j'en fais pratiquement tout les jours plusieurs heures ...

Et bien le C++ justement est encore plus difficile à assimiler. Du fait de son aspect objet, il demande une grande abstraction, mais demande encore beaucoup de connaissances techniques, puisque le système d'allocation-desallocation de mémoire est toujours utilisé. Aprés un an de pratique, je trouve encore que mon code est innaproprié quand je programme en C++. Soit je bidouille comme du C, soit je fait du copier-coller de Java et je déclare des class à tort et à travers. Sans parler de la déclaration de classes ou de fonctions templates ...

Je ne suis pas d'accord. Le C++ offre tout un tas de facilité pour le programmeur. Je pense notemment à la STL grâce à qui on ne devrait plus jamais avoir à faire de new pour déclarer et utiliser un tableau. Je pense égalements aux fonctions templates qui permettent de se passer du type void* etc... Tout ca facilite énormément l'appréhension de la "programmation" plus que de la "manière de programmer". J'entends par là que le C++ (et encore plus le Java) permet de se concentrer sur l'algorithme et la structure plus que sur la gestion de la mémoire et compagnie. Le C++ peut se maîtriser plus rapidement que le C si on fait preuve d'une certaine rigueur.

En résumé, d'aprés mon expérience, le C++ est un langage qui demande beaucoup de maturité de la part du programmeur. Aussi, quand les entreprises développent des applis, si elles peuvent se passer du C++ pour utiliser un autre langage elles le feront. C'est pourquoi, à mon humble avis, le C++ est relativement peu utilisé par rapport à d'autres langages comme le Java, mais par contre, les domaines qui l'utilisent ne sont pas prêts de changer de langage.

Ah non là je suis pas d'accord du tout du tout du tout. Le C demande une très très grande maturité de la part du programmeur car il va devoir tout faire à la main, tout gérer et tout optimiser ! Le C++ te tiens quand même par la main pour de nombreuses choses que tu n'as pas à recoder !

Seulement ces 2 langages ne sont pas des langages pour débutant, ils nécessitent une immense rigueur envers soi-même et les codes qu'on écrit. Ils demandent de constamment se remettre en question et remettre en question ce qui étais vrai hier. Très peu de personnes peuvent prétendre faire du bon C, beaucoup plus peuvent dire faire du bon C++.

[mat.M]

En fait, je suis d'accord sur l'idée que c'est un langage batard,

Tout à fait ( cela a déjà été dit sans doute précedemment ) : C++ est une surcouche objet comme chacun le sait sur le language C.

Et les OS,on ne va pas les ecrire en JAVA ou C# non?????quand meme....il faudrait imperativement avoir un P5(je ne sais si c'est le nom du sucesseur de la famile des P4) pour pouvoir utiliser cet OS la....

AU niveau du CPU
il faudra tjs du code machine et des instructions comme MOV EAX , JMP etc.
Le CPU qui traitent des instructions comme try , catch , if().... ect n'existe pas

A moins qu'une nouvelle génération de processeurs évolués soient fabriqués.
A vous de les imaginer

Ce que je dis est purement fantaisiste aujourd'hui, mais il arrivera un moment où les processeurs "migreront" vers un tout nouveau système qui fera alors oublier les instructiosn assembleurs ...

cf remarque précédente

Seulement ces 2 langages ne sont pas des langages pour débutant, ils nécessitent une immense rigueur envers soi-même et les codes qu'on écrit.

Bjarne Soustrup a voulu développer , à mon sens , un language faisant preuve de trop d'abstraction et complexité qui est souvent difficile à appliquer en pratique

[kaisse]

Quant au C, j'ai vraiment mis 5 mois à bien le maitriser

5 mois ? Ca fait 3 ans et demi que je fais du C et je ne dirais pas que je le maîtrise à 60 voir 70%. Et pourtant j'en fais pratiquement tout les jours plusieurs heures ...

Il faut s'entendre sur maitriser je pense. C'est surement prétentieux de ma part en effet, j'aurais du employer un autre terme. Disons que j'ai mis 5 mois à génerer du code C cohérent et standard, c'est ca ce que je voulais dire par "maitriser". Presque tout ce que j'ai écris en C pendant ses 5 mois était soit plein d'erreurs, soit vraiment trés laid. Aprés 5 mois, mes fonctions avaient des buts précis, et elles commencaient à faire les choses proprement, notamment au niveau de la mémoire. C'est aprés ces 5 mois que je ne traitais plus les tableaux et les pointeurs de la même manière.

Ca fait maintenant un an que je fais du C, et j'en apprends encore tous les jours (enfin tous les jours où j'en fais ). Je sais que j'ai encore beaucoup de chemin et de travail avant d'avoir une "bonne maitrise". Rien qu'à en juger par tes (Yabo) posts sur le forum C, il me faudra du temps pour prétendre avoir le même niveau.

Pour les remarques sur le C++:
effectivement la STL simplifie énormément les choses. Je suis d'accord pour l'exemple des tableaux que j'agrémenterais d'une anecdote: j'ai relu les projets C++ que j'ai fait depuis le début de l'année: pas un seul tableau de style C, pas une seule utilisation des opérateurs new[] et delete[]: que des vector, list et compagnie ...

En fait je m'aperçois que je me suis trompé dans mon post: ce n'est pas tant la "maitrise" du langage qui est difficile (compte tenu des facilités que procurent la STL et la conception objet) mais l'apprentissage qui est plus complexe car plus diversifié (valeurs, pointeurs, références, fonctions, classes, surcharge de fonctions, d'opérateurs, templates + apprentissage de la STL, notamment les conteneurs).

Pardon pour toutes ces erreurs...

[Luc Hermitte]

Quelques transparents d'une conf d'Herb Sutter qui sont en thème, je pense (*), avec le sujet du fil de discussion : l'avernir du C++.
http://www.accu.org/conference/prese..._(keynote).pdf

Les transparents 12 et plus (qui ne parlent pas de syntaxe mais plus d'idiomes) sont je pense les plus intéressants -- bon d'accord, ils comparent l'application type du RAII au dispose pattern des autres langages qui n'ont qu'un GC et finally.

(*) Bien que cela s'éloigne quelques peu du standard

PS: les blogs du monsieur et de ses collègues sont également très intéressants.

[Caine]

Sérieusement,
ai-je encore, aprés Java et .Net, une chance de trouver un jour une entreprise qui embauche pour développer uniquement en C++.

Car aprés une formation en cours du soir au Cnam, je suis "mordu" de ce langage.

Je suis déjà mordu de l'objet, mais maintenant, je souhaiterais vraiment me spécialiser en C++.

Mais les offres sont de plus en plus rares dans ce cas, est-ce un signe ?

[HRS]

plutôt que la connaissance du C++, une entreprise demandera la
maîtrise de l'outil C++Builder ou VC++

d'ailleurs .net peut se faire en VC++

[ovh]

Sinon essaie de te faire embaucher dans une société de dev de jeu, là ils doivent encore bien utiliser ce langage je pense

[Caine]

J'ai la chance d'être en poste.

Pour moi la question est: Y-a-t-il encore une majorité d'entreprises développant en C++ (quelque soit l'EDI, VC++, C++Builder ou autre)

Ensuite, mais ceci trouverait ça place dans les débats sur l'embauche, je trouve plus important de connaitre le langage, aprés les outils se ressemblent plus ou moins.

[Luc Hermitte]

Je détère ce vieux post pour y rajouter une "news" que certains connaissent déjà.

A brief look at C++0x by Bjarne Stroustrup

[Marc Lussac]

Il semblerais que C++ soit toujours un langage très utilisé, même sur www.developpez.com : C++ est la rubrique numéro 2 en fréquentation, juste derrière Java, ce qui n'est pas rien...

[Breuleux]

Tout dépend de ce qu'on veut dire par "avenir". Si on parle de l'avenir immédiat C et C++ n'ont rien à craindre. Il y a beaucoup de domaines (systèmes d'exploitation, pilotes, langages, etc.) où ils demeurent la seule option viable. Et puis par rapport à Java/C# la différence n'est pas si grande; personnellement, sous plusieurs aspects, je trouve Java plus pénible à utiliser que C et C++ (C#, je ne le connais pas, mais j'ai entendu de bonnes choses à son sujet). En ce moment j'utilise C++ pour tout ce qui demande de la performance et Ruby pour tout le reste.

Dans 10-15 ans, la situation sera différente. C et C++ resteront en utilisation (tout langage a son fan club), mais des langages avec GC et bytecode comme Java et C# (ou peut-être un nouveau langage, qui sait) les auront remplacés à peu près partout, tout simplement parce que les progrès en matière de JIT auront comblé la différence de performance. En d'autres mots, la JVM sera écrite en Java, le système d'exploitation sera écrit en Java, et ça sera aussi performant que si tout avait été écrit en C, sinon davantage.

Le principe dont il faut se rappeler c'est que plus un langage est bas niveau, moins le compilateur/interpréteur/jit a de latitude pour optimiser. Si le programmeur est meilleur que la machine pour prendre soin des détails de bas niveau, ça va bien, mais à mesure que la machine devient plus sophistiquée, de moins en moins de programmeurs seront meilleurs qu'elle et soudainement les malloc, free, l'arithmétique de pointeurs et cie deviennent non seulement inutiles mais problématiques: disons que le compilateur voit un new Patapouf() dans le code qui ne sort pas de la portée de la fonction et qui n'est pas libéré. Il aimerait bien remplacer ça par une allocation sur la pile. Mais est-ce qu'il a le droit de le faire? Qu'est-ce qui se passe si c'était intentionnel et que le programmeur manipule des pointeurs on ne sait trop comment pour aller chercher cet objet par la suite? S'il prend le risque de changer le code, comment expliquer au programmeur pourquoi ça ne marche pas?

En d'autres mots, les langages de haut niveau vont éventuellement battre les langages de bas niveau. C'est inéluctable. Si vous voulez un exemple, Stalin, un compilateur Scheme, est déjà capable de générer du code C plus performant que ce qu'un humain moyen pourrait faire à la main. Bien sûr, ça prend un temps fou à compiler, mais cela deviendra raisonnable avant longtemps. Comme Java et C# sont relativement proches de C et C++, ils seront probablement à leur niveau dans peu de temps. Suivront les langages dynamiques comme Python ou Ruby et puis qui sait quoi par la suite.

Je précise toutefois que ça va prendre des dizaines d'années.

[ash.ice.loky]

Oui, je ne pense pas que C++ soit menacé de si tot.

C#, .NET, ... sont sympa mais seulement sous windows, exit le monde du free.

JAVA reste du code pseudo-interprété et meme si la derniere JVM optimise de facon sympa les perf. certain domaine necessitant une certaine rapidité ne peuvent se permettent de l'utiliser.

Je pense par exemple à la recherche, avec des outils de parralélisations, de compilation, de partitionnement, de Systeme, ...

Maintenant dans le monde del'entreprise moderne ou les IHM prime souvent sur la perf, C++ disparait pour 2 raisons :
- le portage inutile (WIN 100%)
- difficulté de créer une GUI par rapport aux autres langages.

Je suis étonné dans el monde des grandes entreprises de l'avancé de PHP pour des raisons de distributions d'appli.

[outs]

mais des langages avec GC et bytecode comme Java et C# (ou peut-être un nouveau langage, qui sait) les auront remplacés à peu près partout, tout simplement parce que les progrès en matière de JIT auront comblé la différence de performance. En d'autres mots, la JVM sera écrite en Java, le système d'exploitation sera écrit en Java.

Mouhahaha un OS en Java Bon alors dans vraiment très longtemps alors, genre le Java ne sera plus ce qu'il est actuellement.

Mais la quesion que tout le monde se pose est : <<a quoi cela sera de compiler en bytecode pour machine virtuelle si c'est pour compiler a la volé JIT en code natif ?>> Cela serait quand même considérablement plus simple de compiler directement en code natif. Moi ce que je vois surtout c'est que les machines virtuelles servent de surcouche par dessus le système d'exploitation pour le rendre plus puissant. Ce qu'il faudrait faire c'est modifier directement le SE pour inclure les améliorations des machines virtuelles dedans.

Le principe dont il faut se rappeler c'est que plus un langage est bas niveau, moins le compilateur/interpréteur/jit a de latitude pour optimiser..

Tout à fait d'accord, mais le Java/C# ne sont pas si haut-niveau que cela. On pourrait même dire que le Java est un langage simpliste par rapport aux possibilité de certain langages objets. C'est pour cela que ca va être très dur de rendre le Java très rapide, le langage n'est pas bien adapté pour cela. C# c'est un peu mieux et il y a des bonnes idée mais il reste du chemin a parcourir.

Comme Java et C# sont relativement proches de C et C++, ils seront probablement à leur niveau dans peu de temps. Suivront les langages dynamiques comme Python ou Ruby et puis qui sait quoi par la suite..

A part que le niveau d'optimisation du C++ n'est pas terrible, la plupart des optimisations son géré a la main par le programmeur : fonction non virtuelle, inlining, pointeurs...

Et le problème des langages <<dynamiques>> (ca veut rien dire ca ... bref) est qu'ils se permettent des choses possibles uniquements avec un gros support d'éxecution. Et ca c'est très dur à optimiser.

[Breuleux]

Mais la quesion que tout le monde se pose est : <<a quoi cela sera de compiler en bytecode pour machine virtuelle si c'est pour compiler a la volé JIT en code natif ?>> Cela serait quand même considérablement plus simple de compiler directement en code natif. Moi ce que je vois surtout c'est que les machines virtuelles servent de surcouche par dessus le système d'exploitation pour le rendre plus puissant. Ce qu'il faudrait faire c'est modifier directement le SE pour inclure les améliorations des machines virtuelles dedans.

Le JIT a davantage d'informations à sa disposition pour générer du bon code natif. Par exemple, il peut optimiser en fonction de la taille du cache, du pourcentage d'utilisation de telle ou telle fonction, etc. Or, c'est plus facile de faire ça à partir d'un bytecode qu'à partir du code natif (qu'on doit par ailleurs obtenir pour toute architecture cible). Mais si on veut, on peut mettre le code natif en cache et en théorie on pourrait même distribuer le bytecode avec des bouts natifs de différentes architectures qui ont été optimisés avec soin à force d'usage. Dans ces cas-là, cela reviendrait un peu au même que de le compiler une première fois, plus quelques avantages.

Je suis d'accord qu'une meilleure intégration avec le système d'exploitation serait une bonne idée.

Tout à fait d'accord, mais le Java/C# ne sont pas si haut-niveau que cela. On pourrait même dire que le Java est un langage simpliste par rapport aux possibilité de certain langages objets. C'est pour cela que ca va être très dur de rendre le Java très rapide, le langage n'est pas bien adapté pour cela. C# c'est un peu mieux et il y a des bonnes idée mais il reste du chemin a parcourir.

Oui, c'est vrai Java est du C++ sans pointeurs, avec GC et forçant une organisation en objets plus stricte. Il n'y a pas grand chose d'autre à dire; les entiers/tableaux ne sont pas des objets, il n'y a pas de lambdas, pas de typage dynamique, un foreach apparu sur le tard, pas de macros, de génération de code ou de métaprogrammation, sans dire que tout langage de haut niveau devrait avoir tout ça, il manque quand même pas mal d'abstractions. Sûr, il y a des outils, mais bof...

En tout cas, la différence entre ASM et C++ est bien plus grande que celle qui existe entre C++ et Java. C'est donc possible que Java ne tue jamais C++, tout simplement parce la différence entre les deux n'est pas assez prononcée.

A part que le niveau d'optimisation du C++ n'est pas terrible, la plupart des optimisations son géré a la main par le programmeur : fonction non virtuelle, inlining, pointeurs...

Pour le moment, c'est son avantage. Si C++ commençait à s'occuper de tout ça, il n'aurait plus vraiment d'attrait.

Et le problème des langages <<dynamiques>> (ca veut rien dire ca ... bref) est qu'ils se permettent des choses possibles uniquements avec un gros support d'éxecution. Et ca c'est très dur à optimiser.

C'est juste, mais une grande partie de leur code peut être compilée pour être aussi efficace que du C. Il y a plusieurs façons de faire. Étant donné un typage dynamique, on peut fabriquer plusieurs versions d'une même fonction pour différents types et tenter le plus possible d'utiliser les versions spécialisées. On peut profiler le code et remplacer les tables de hachage par une structure de type C, quitte à essuyer un gros coût si la structure est modifiée. En ce qui a trait à l'évaluation dynamique de code, il suffit de regarder toutes les applications qui utilisent des langages de script pour spécialiser leur comportement

Remarque que je ne crois pas que les langages avec typage dynamique vont supplanter les langages avec typage statique, tout simplement parce que de dire que "f s'applique sur des nombres entiers" fait partie de la définition d'un programme. Si je définis la fonction factorielle je m'attends à ce que le programme plante si je l'utilise sur une chaîne de caractères, même si le langage a décidé que "123"-1 est valide et donne "23" et que "a"*"b" est valide et donne "ab". C'est aussi très utile pour déboguer. D'un autre côté, cela demande un certain effort et cet effort n'est pas toujours justifié, surtout si on veut prototyper.

Je crois que des langages avec typage optionnel vont gagner de la popularité. J'aimerais bien coder un programme sans types pour pouvoir le faire fonctionner plus vite et essayer plusieurs structures différentes, et une fois que je suis content de ma structure j'aimerais bien pouvoir rendre mon programme plus robuste avec des déclarations de types.

[mat.M]

Pour moi la question est: Y-a-t-il encore une majorité d'entreprises développant en C++ (quelque soit l'EDI, VC++, C++Builder ou autre)

Oui celles qui font de l'analyse boursière ; les projets sont entièrement en C++, regarder les petites annonces.
Ou bien tout ce qui a attrait au temps réel, multimédia
La boite ou je bosse la partie VB est de + en + délaissée pour C++ ( ATL-COM)

plutôt que la connaissance du C++, une entreprise demandera la
maîtrise de l'outil C++Builder ou VC++

Absolument ; c'est dur à faire comprendre aux gens de ce forum mais ce n'est pas un langage mais plutot un outil qu'il faut maitriser.
C++ tout seul ne sert pas à grand chose

Dans 10-15 ans, la situation sera différente. C et C++ resteront en utilisation (tout langage a son fan club), mais des langages avec GC et bytecode comme Java et C# (ou peut-être un nouveau langage, qui sait) les auront remplacés à peu près partout, tout simplement parce que les progrès en matière de JIT auront comblé la différence de performance.

Cela est contestable ; regarde les performances des CPU , elles n'évoluent plus vraiment.
On nous dit que les perfs des CPU suivent la loi de Moore , magnifique théorême commercial dont le seul but n'est que de remplir les caisses des fabricants de CPU.
Et puis en 15 ans les JVM et .NET framework seront des surcouches lourdingues de plusieurs megas auquel on rajoute des tas de trucs inutiles.
Regarde la lourdeur du framework .NET , combien de Mo à télécharger ; et tu parles d'un truc optimisé toi ?
Admettons 25 Mo de Framework sur disque , le quadruple à charger en mémoire.

Et cerise sur le gateau avec .NET il y a des trucs que tu ne peux pas faire sans passer par du code natif ; par exemple en .NET quid de filtres Direct Show.
Veux-tu que je te sorte un topic ou la personne est obligée de bricoler en .NET et code natif parce que l'éditeur n'a pas totalement tout prevu ou parce que c'est techniquement pas possible de faire en bytecode ?

Le principe dont il faut se rappeler c'est que plus un langage est bas niveau, moins le compilateur/interpréteur/jit a de latitude pour optimiser

Pourquoi je te prie ? On ne peut pas plus optimiser vu que c'est de + en + bas-niveau !
Après pour optimiser la cela devient de l'électronique.

disons que le compilateur voit un new Patapouf() dans le code qui ne sort pas de la portée de la fonction et qui n'est pas libéré.

Monsieur Breuleux apparement vous ne connaissez pas du tout les principes de compilation.
Pour la 1000ieme fois la compilation et l'exécution pour un langage en code natif sont différents.
Le compilateur pour lui un new , fut-il sans delete c'est parfaitement correct et ça reste dans les régles de grammaire du compilateur.

Mais la quesion que tout le monde se pose est : <<a quoi cela sera de compiler en bytecode pour machine virtuelle si c'est pour compiler a la volé JIT en code natif ?>> Cela serait quand même considérablement plus simple de compiler directement en code natif.

+1

Le JIT a davantage d'informations à sa disposition pour générer du bon code natif. Par exemple, il peut optimiser en fonction de la taille du cache,

Eh attention !
De quel cache s'agit-il ?? Faut etre précis .Si c'est du cache CPU , Java ne connait ABSOLUMENT pas parce que c'est en théorie censé tourner sur n'importe quelle plateforme.
Est-ce qu'il ya une JVM optimisée pour Intel , pour AMD , pour SSE , pour MMX ??

[Breuleux]

Cela est contestable ; regarde les performances des CPU , elles n'évoluent plus vraiment.
On nous dit que les perfs des CPU suivent la loi de Moore , magnifique théorême commercial dont le seul but n'est que de remplir les caisses des fabricants de CPU.

Tu as raison sur la loi de Moore, mais ce n'est pas vraiment la même situation. Le problème avec l'évolution des CPU c'est qu'on se heurte sur des barrières physiques. On ne peut presque plus miniaturiser parce que ça fuit comme c'est pas possible. Ça va débloquer éventuellement, mais il faudra probablement utiliser des technologies radicalement nouvelles.

Pour les compilateurs c'est différent. Premièrement, les optimisations que les JIT font sont probablement faciles à paralléliser, et donc on peut prendre avantage des multi-processeurs (qui prolifèrent justement parce que c'est rendu le moyen facile d'augmenter la puissance). Deuxièmement, il y a sûrement toutes sortes de méthodes ingénieuses qui ne coûtent presque rien et qui n'attendent que d'être découvertes. Faut être optimiste quand même!

Et puis en 15 ans les JVM et .NET framework seront des surcouches lourdingues de plusieurs megas auquel on rajoute des tas de trucs inutiles.
Regarde la lourdeur du framework .NET , combien de Mo à télécharger ; et tu parles d'un truc optimisé toi ?
Admettons 25 Mo de Framework sur disque , le quadruple à charger en mémoire.

C'est un peu embarrassant, j'avoue, mais je crois que le problème va aller en diminuant. D'une part, les machines virtuelles seront idéalement ancrées dans le système d'exploitation, et d'autre part les upgrades seront distribués de manière plus incrémentale de sorte qu'on ne remarquera plus rien.

Et cerise sur le gateau avec .NET il y a des trucs que tu ne peux pas faire sans passer par du code natif ; par exemple en .NET quid de filtres Direct Show.
Veux-tu que je te sorte un topic ou la personne est obligée de bricoler en .NET et code natif parce que l'éditeur n'a pas totalement tout prevu ou parce que c'est techniquement pas possible de faire en bytecode ?

C'est un bon point. Il est difficile de tout prévoir. On verra bien

Monsieur Breuleux apparement vous ne connaissez pas du tout les principes de compilation.
Pour la 1000ieme fois la compilation et l'exécution pour un langage en code natif sont différents.
Le compilateur pour lui un new , fut-il sans delete c'est parfaitement correct et ça reste dans les régles de grammaire du compilateur.

Je ne crois pas que tu aies compris mon point. Je te parle d'un compilateur intelligent. Le compilateur intelligent ne fait pas que traiter la grammaire, il essaie de comprendre ton code pour voir s'il peut faire quelque chose pour l'améliorer. S'il peut prouver que ton code a une fuite de mémoire (il n'est pas toujours nécessaire de l'exécuter pour s'en rendre compte) et qu'il est capable de la boucher, il ne va pas se gêner.

Le problème c'est qu'en C ou en C++ il est extrêmement difficile de faire ce genre de preuve. Il n'y a aucun cas simple. Un langage comme Java pourrait regarder ton code, voir qu'il est impossible que tel objet soit réutilisé et puis décider de l'enlever sans même passer par le GC. En C/C++ il faudrait carrément explorer le programme en entier pour éliminer les doutes.

Eh attention !
De quel cache s'agit-il ?? Faut etre précis .Si c'est du cache CPU , Java ne connait ABSOLUMENT pas parce que c'est en théorie censé tourner sur n'importe quelle plateforme.
Est-ce qu'il ya une JVM optimisée pour Intel , pour AMD , pour SSE , pour MMX ??

Évidemment. Lorsque tu exécutes un programme Java, la JVM va traduire le bytecode en code natif de ta machine. À moins que la JVM ne soit qu'un simple interpréteur, elle doit connaître ta machine et être capable d'en tirer le maximum.

Le code natif qui va être généré va dépendre de la taille de ton cache, entre autres. Le bytecode est portable, mais cela n'empêche pas que pour des raisons de performances il va être traduit en natif spécialisé sur chaque machine sur laquelle il roule.

[mat.M]

Je ne crois pas que tu aies compris mon point. Je te parle d'un compilateur intelligent. Le compilateur intelligent ne fait pas que traiter la grammaire, il essaie de comprendre ton code pour voir s'il peut faire quelque chose pour l'améliorer. S'il peut prouver que ton code a une fuite de mémoire (il n'est pas toujours nécessaire de l'exécuter pour s'en rendre compte) et qu'il est capable de la boucher, il ne va pas se gêner.

Ok nous sommes d'accord mais la technique exposée me semble un peu fastidieuse et ardue à mettre en oeuvre