Discussion :

[Mouke]

J'ai commencé le C++ dans le cadre mes études. C'est mon premier langage objet et, aujourd'hui encore, il reste mon préféré.

Sur le plan pédagogique, je le préfère à Java, C# ou aux langages de scripts comme Python : J'ignore si les dernières normes ont changé ça, en tout cas C++ (impose ?) permet la gestion mémoire avec les pointeurs et les malloc, il n'a pas de Garbage Collector (une aberration pédagogique à mes yeux), permet l'apprentissage de bas niveau comme de haut niveau. Les langages plus haut niveaux ont tendance à faire abstraction de concepts qui sont, à mes yeux, importants d'appendre. Mais je pense que, 30ans dans le passé, on considérait de cette manière le C++.

Sur le plan pro, je n'ai pas encore eu la chance de travailler en C++. Néanmoins, quand je vois son usage et tous les outils qui lui sont proposés, effectivement, C++ est un outil très puissant. Certains domaines n'ont pas d'alternative à C++ d'ailleurs.

j'apprécie par contre que M. Stroustrup ne néglige pas pour autant le domaine du script :

« Le C++ est conçu pour les applications lourdes, il ne se focalise pas sur la facilité d’utilisation, par contre il a toujours été utilisé conjointement avec un langage de script »

Effectivement, dans certains domaines, inutile de déployer du C++ avec un gros framework. Un script léger et performant, comme Python, fera totalement l'affaire.

De même, comme dit plus haut, c'est dommage que C++ ne propose pas une solution web suffisamment efficace...

Encore un qui oublie que ce bon vieux COBOL est le maitre incontesté dans les finances malgré sa discrétion.

Actuellement en stage dans une banque, je me permets de compléter : Effectivement, point de C++. Du COBOL, du Natural, beaucoup de Java aussi (ça m'a surpris d'ailleurs le Java). Il me semble qu'il y a encore 75% de l'informatique financier qui fonctionne en COBOL dans le monde.
Néanmoins, le C++ ne me choquerait pas dans la finance.

[jm130794]

Bonjour,

Pour les applications WEB, il existe tntnet. J'utilise régulièrement ce logiciel et je peux vous assurer qu'il est très simple à prendre en main.

Le développement d'application Web se fait en quelques minutes. Le préprocesseur eccpc vous permet d'écrire des pages HTML aussi facilement qu'avec du PHP ou autres langages de scripts. L'écriture de services REST est enfantin.

Cerise sur le gâteau, vous pouvez tout inclure dans un seul exécutable : serveur HTTP, images, pages html ou javascrpt, etc

Fini les CGI...

Par contre, pas de version pour Windows.

Jean-Marc

[redcurve]

Bonjour,

Pour les applications WEB, il existe tntnet. J'utilise régulièrement ce logiciel et je peux vous assurer qu'il est très simple à prendre en main.

Le développement d'application Web se fait en quelques minutes. Le préprocesseur eccpc vous permet d'écrire des pages HTML aussi facilement qu'avec du PHP ou autres langages de scripts. L'écriture de services REST est enfantin.

Cerise sur le gâteau, vous pouvez tout inclure dans un seul exécutable : serveur HTTP, images, pages html ou javascrpt, etc

Fini les CGI...

Par contre, pas de version pour Windows.

Jean-Marc

Pour du REST tu peux utiliser aussi Casablanca : http://casablanca.codeplex.com/

[jm130794]

Pour du REST tu peux utiliser aussi Casablanca : http://casablanca.codeplex.com/

Je sais

Néanmoins, si l'asynchrone n'est pas une priorité, tntnet offre beaucoup plus de possibilités que Casablanca.

Ses atouts :
- il et est plus mature,
- la documentation est bien faite,
- il gère les formats XML, JSON, CVS, ... sans bibliothèques supplémentaires,
- les pages HTML seront transformées en composant C++ natif si nécessaire,
- il intègre une gestion des logs par niveau (DEBUG, ERROR, TRACE, INFO, ...
- les ressources peuvent être intégrées au programme,
- on peut faire autre chose que du REST,
- ...

Je n'ai pas dit que Casablanca est à éviter, loin de là mais utiliser tntnet peut mettre en évidence que les applications Web peuvent très bien être réalisées en C++.

Jean-Marc

[smarties]

Je ne connaissais pas tntnet ni Casablanca.

Je jetterais un œil prochainement... pour un petit projet pour commencer à la limite

[Uther]

J'en pense que c'est un langage qui s'offre des mécanismes de sureté très efficace, pour peu qu'on apprenne à les utiliser.

Sauf que c'est aussi le langage qui laisse a disposition le plus de mécanismes permettant de se tirer un balle dans le pied. Les mécanismes sécurisés du langages sont optionnel et moins triviaux à utiliser que leurs équivalents non surs. Donc même s'il est possible en faisant bien attention de faire des chose plus ou moins sures avec du C++, ce n'est certainement pas son atout.
Ces principaux points forts sont pour moi avant tout ses performances et l’héritage du C (même si c'est aussi un de ses plus gros point faible).

Sur le plan pédagogique, je le préfère à Java, C# ou aux langages de scripts comme Python : J'ignore si les dernières normes ont changé ça, en tout cas C++ (impose ?) permet la gestion mémoire avec les pointeurs et les malloc, il n'a pas de Garbage Collector (une aberration pédagogique à mes yeux), permet l'apprentissage de bas niveau comme de haut niveau. Les langages plus haut niveaux ont tendance à faire abstraction de concepts qui sont, à mes yeux, importants d'appendre. Mais je pense que, 30ans dans le passé, on considérait de cette manière le C++. .

Le pense que sur un plan pédagogique des langages comme Basic, Java, ... sont idéal pour commencer pour travailler avec les notion d'algorithme simple (itération, condition structures, ...) .
Maitriser des langages plus bas niveau comme le C ou le C++ qui ont une gestion manuelle de la mémoire est bien sur quelque chose d'obligatoire a apprendre, mais a mon avis plus tard, car ils nécessitent de maitriser beaucoup trop de notions très complexes pour ne pas faire n'importe quoi avec.

Sur le plan pro, je n'ai pas encore eu la chance de travailler en C++. Néanmoins, quand je vois son usage et tous les outils qui lui sont proposés, effectivement, C++ est un outil très puissant. Certains domaines n'ont pas d'alternative à C++ d'ailleurs.

Je serais surpris de savoir lesquels. Pour moi, des langages comme le C, D, Ada, ... sont presque toujours des alternatives tout a fait valables au C++.
Les seuls cas gênants que j'aie rencontré, c'est quand on doit s'interfacer avec une bibliothèque conçue uniquement pour le C++. Car le C++ est un plaie a interfacer tel quel avec d'autre langages il faut passer par une interface C, mais dans certains cas ça peux devenir lourd.

[ternel]

Un avantage du C++, c'est que le tirage dans le pied est plus rare.
Un gros inconvénient, c'est que ça fait toujours très mal.

[Luc Hermitte]

Voire que les tirages dans le pied qui restent sont les plus douloureux.

Sinon, Uther, BASIC pour débuter ? Sérieusement ?

Et BTW, maitriser le C++ rime avec une gestion de la mémoire non manuelle (la faute aux exceptions; autrement il est impossible d'écrire des programmes robustes et maintenables ; et ne pas savoir écrire des programmes robustes et maintenable est un signe que l'on ne maitre pas le langage).

[stalacta]

Le succès du C++ est dû à sa rapidité, c'est indéniable. Et énormément de programmes requièrent de la rapidité. Mais son défaut est que ce n'est pas le langage qui offre les solutions les plus simples à la plupart des problèmes. On doit donc choisir entre rapidité de développement ou d'exécution. Mais le bon compromis reste d'utiliser le C++ pour des parties rapides d'un programme (le cryptage et la compression pour une vidéo-conférence par exemple) et d'utiliser un langage plus haut niveau qui peut utiliser des dll et est souple, comme le Python par exemple.

[super_navide]

Moi j'aime pas C++ et préfère java pour les raison suivantes :
la syntaxe de java est plus simple.
Le C++ n'a pas de garbage collector.
Le C++ n'a pas d'API de d'introspection comme java.reflect.
Le C++ doit recompiler pour être exécuter sur d'autre plateforme.

Oui C++ est très performant mais au prix d'une complexité importante dans le temps java prendra le dessus mais C++ restera comme le COBOL.
Car aujourd'hui la performance ce sont les carte graphique avec les shaders qui explose n'importe quel programme C++ au niveau performance.

Donc C++ comme COBOL ca existera toujours pour les intégristes qui ne savent pas évoluer vers d'autre langage....

Je pense que java est Le Langage de programmation qui permettra de tous faire dans ses futures versions.

[foetus]

la syntaxe de java est plus simple.

Bof, même si la grammaire du C++ est ambiguë, il n'y pas vraiment de truc tordu.
Juste des fonctionnalités qui rajoutent "une autre forme de coder"

Le C++ n'a pas de garbage collector.

Mais tu peux coder ton propre ramasse-miette. Eugen Systems le fait pour leurs jeux

Le C++ n'a pas d'API de d'introspection comme java.reflect.

Cela se défend. Il y a le RTTI et des vieilles techniques (comme mettre le nom de la classe dans la classe par exemple)

Mais en règle générale, lorsque tu fais cela en C++, cela commence à sentir mauvais pour ton code

Le C++ doit recompiler pour être exécuter sur d'autre plateforme.

C'est même mieux Lorsque tu vois les différences entre les plateformes tu m'étonnes que tu ne puisses pas

Car aujourd'hui la performance ce sont les carte graphique avec les shaders qui explose n'importe quel programme C++ au niveau performance.

Vieux débat entre CPU généraliste (comme les CPUs) et un CPU spécialiste (comme les GPUs)

Et mine de rien, faire un programme full-shader n'est pas possible (ce sont les pilotes qui redirigent le travail si je ne dis pas de bêtises).
Et OpenCL n'arrive pas à décoller

Donc C++ comme COBOL ca existera toujours pour les intégristes qui ne savent pas évoluer vers d'autre langage....

N'importe quoi. Un langage == un domaine d'application.
Tu t'imagines qu'au lieu du javascript ce soit du C++
Et inversement, tu t'imagines coder un logiciel (un truc sérieux) en javascript ou Ruby voire Python

[Iradrille]

Moi j'aime pas C++ et préfère java pour les raison suivantes :
la syntaxe de java est plus simple.

Je te l'accorde.

Le C++ n'a pas de garbage collector.
Le C++ n'a pas d'API de d'introspection comme java.reflect.

Question de point de vu surement, ce sont pour moi les deux plus gros avantages du C++ sur Java.

Le C++ doit recompiler pour être exécuter sur d'autre plateforme.

Tout comme une JVM doit être présente sur toute machine cible pour le Java, mais oui, le fait que le langage ne soit pas multiplatforme est un défaut (il est tout à fait possible d'écrire du code portable cependant).

Car aujourd'hui la performance ce sont les carte graphique avec les shaders qui explose n'importe quel programme C++ au niveau performance.

Tous les algos ne s'y prettent malheuresement pas.

Je pense que java est Le Langage de programmation qui permettra de tous faire dans ses futures versions.

Même une JVM ?

[Saverok]

Je pense que java est Le Langage de programmation qui permettra de tous faire dans ses futures versions.

As-tu au moins lu l'article ??
L'auteur dit très clairement que le C++ n'est pas adaptés aux applications "modernes"
Java (ou autre langage de haut niveau) n'a pas les mêmes domaines d'applications que le C++
A chaque domaine, ses outils

Il y a eu plusieurs projets de faire des systèmes embarqués avec Java
Ca a été des échecs car Java est trop haut niveau justement et qu'il a fallu tailler dans le vifs pour l'alléger lui faisant perdre tous ses avantages par l’allègement de son jeu d'instruction. Et le tout, avec des perf moindre que le C++
La simple existence de la JVM provoque une consommation mémoire (et donc de batterie) incompatible avec les systèmes embarqués.

Je suis développeur Java depuis 10 ans et je kiffe ce langage mais ça n'empêche pas d'être conscient de ses faiblesses et de ses capacités

[JolyLoic]

Oui C++ est très performant mais au prix d'une complexité importante dans le temps java prendra le dessus mais C++ restera comme le COBOL.
Car aujourd'hui la performance ce sont les carte graphique avec les shaders qui explose n'importe quel programme C++ au niveau performance.

Et qu'est-ce qui empêche de programmer une carte graphique en C++ ? Tu mélanges langage de programmation et cible de compilation... Il y a déjà des bibliothèques/extensions C++ pour gérer la carte graphique (ArrayBuildingBlocks d'Inter, C++Amp de Microsoft, et probablement plein d'autres), même si ça reste un domaine à évolutions rapides. Et pour information, parmi les gens qui travaillent sur les évolutions du C++ pour le parallélisme, il y a des gens de chez NVidia. Ce n'est certainement pas sans une bonne raison...

[super_navide]

Et qu'est-ce qui empêche de programmer une carte graphique en C++ ? Tu mélanges langage de programmation et cible de compilation... Il y a déjà des bibliothèques/extensions C++ pour gérer la carte graphique (ArrayBuildingBlocks d'Inter, C++Amp de Microsoft, et probablement plein d'autres), même si ça reste un domaine à évolutions rapides. Et pour information, parmi les gens qui travaillent sur les évolutions du C++ pour le parallélisme, il y a des gens de chez NVidia. Ce n'est certainement pas sans une bonne raison...

Oui je suis d'accord on pourrait imaginer faire tourner du C++ directement sur une carte graphique tous comme du Java.
Moi je parle du langage de shader inspirer du C qui tourne sur la carte graphique.
Celui-ci est simple ne fait d'allocation dynamique et est vraiment simple d'utilisation.

L'avenir c java plus l'utilisation de langage de type "language shader"

Je rappelle que qu'un programme passe 80% de son temps dans 20% du code et généralement ce code peut être écrit en C.

Le seul langage incontournable est le C ou un C like comme le langage des shaders si on veut vraiment de la performance.

[DonQuiche]

Oui je suis d'accord on pourrait imaginer faire tourner du C++ directement sur une carte graphique tous comme du Java.
Moi je parle du langage de shader inspirer du C qui tourne sur la carte graphique.
Celui-ci est simple ne fait d'allocation dynamique et est vraiment simple d'utilisation.

L'avenir c java plus l'utilisation de langage de type "language shader"

Je rappelle que qu'un programme passe 80% de son temps dans 20% du code et généralement ce code peut être écrit en C.

Le seul langage incontournable est le C ou un C like comme le langage des shaders si on veut vraiment de la performance.

Le C a été (est) utilisé pour les GPU parce que ceux-ci étaient (sont) primitifs. Il s'agissait de grosses usines vectorielles s'effondrant au premier branchement venu, dépourvu de mémoire virtuelle ou de mécanismes de protection, avec une synchronisation inexistante ou bancale, seulement capables de recevoir passivement des ordres du CPU et tout juste aptes à signaler la fin du boulot au CPU. On leur envoyait un gros paquet de données via un bus PCIe bien lent et un passage en kernel mode, puis on récupérait quelques microsecondes plus tard un gros paquet de données via un bus PCIe bien lent.

Ça c'était (c'est) le GPU de grand-papa. Ce qui est en train d'apparaître maintenant, notamment chez AMD (mais les autres suivent, y compris les éditeurs logiciels), ce sont des coeurs GPU intégrés au CPU, toujours vectoriels mais beaucoup pus généralistes, ayant résolu à peu près tous les points mentionnés ci-dessus. Ne reste plus que l'absence de pile d'appels, ce qui sera sans doute résolu dans une ou deux générations.

Donc oui on va faire de plus en plus appel au GPU, mais ce ne sera certainement pas avec du C.
* D'abord parce que personne ou presque n'a envie de programmer en C : peu productif, risqué, etc.
* Ensuite parce qu'écrire ton code dans deux langages, ça veut dire écrire plein de plomberie pour faire cohabiter les deux et beaucoup de redondance.
* Enfin parce que beaucoup d'algorithmes perdent de leur intérêt si tu dois préalablement transformer tes données d'un format vers un autre, et vice-versa au retour.

Sceptique ? Jette un coup d'oeil au projet Sumatra. C'est un gros effort d'AMD et d'autres pour programmer le GPU directement en Java (avec bien sûr des limitations concernant les parties à exécuter sur le GPU mais pas tant que ça).

Plus généralement tout ce problème s'inscrit dans la perspective du calcul hétérogène dans le nuage: autrement dit la capacité à exploiter des architectures spécifiques dans le nuage, tout en payant la plus petite taxe de virtualisation possible. Un acteur comme Microsoft mise pour ça sur un bytecode dont certaines propriétés (isolation mémoire, absence de deadlock avec l'extérieur, etc) sont prouvables (de façon à lever la taxe) et qui aura pour cibles de compilation tant des CPU que des GPU ou autres. Si ce bytecode sera vraisemblablement de plus bas niveau que celui de dotnet, je doute qu'on puisse y compiler efficacement du C. D'ailleurs MS développe un langage de plus haut niveau et plus sécurisé que le C mais d'assez bas niveau pour être dédié à la programmation système tout en tournant sur ce bytecode ; il serait destiné aux pilotes de péirphériques et au coeur du système.

La récupération de la mémoire par un mark and sweep est tres tres tres couteux.

Non. Mais coûteux, oui, tout comme l'ensemble shared_ptr + weak_ptr + allocateur par tas. Souvent moins en fait.

Car il revient a parcourir toute la pile et les variables globales pour marquer les objets accessible, rendez vous compte des performance sur des millions d'objet avec des lien dans tous les sens.

Non, pas des millions d'objets. D'abord parce qu'on n'a pas à visiter les anciens objets (génération 2 - il faudra seulement visiter les pages mémoire modifiées) ni les objets inaccessibles. Ensuite parce que la pile d'appels est en général assez compacte. Enfin parce que c'est un problème mémory-bound mais que les nouveaux objets sont tous dans le cache L3 ou inférieur.

Mon explication est encore loin de la réalité car le mark and weep peut je croix maintenant ce faire sans en parallel sans geler la machine virtuel.

Des algos de ce genre existent, oui, mais ils obligent à utiliser des formes de synchronisation à tel ou tel moment et ne sont donc pas forcément plus intéressants. Comme d'hab il n'y a pas de magie. A ma connaissance (mais je ne suis pas spécialiste) il est généralement plus rapide d'arrêter les threads (voire de les arrêter indépendamment pour les serveurs webs) mais de ne faire que le strict minimum à ce moment-là et reporter le reste de la charge à plus tard.

[super_navide]

Le C a été (est) utilisé pour les GPU parce que ceux-ci étaient (sont) primitifs. Il s'agissait de grosses usines vectorielles s'effondrant au premier branchement venu, dépourvu de mémoire virtuelle ou de mécanismes de protection, avec une synchronisation inexistante ou bancale, seulement capables de recevoir passivement des ordres du CPU et tout juste aptes à signaler la fin du boulot au CPU. On leur envoyait un gros paquet de données via un bus PCIe bien lent et un passage en kernel mode, puis on récupérait quelques microsecondes plus tard un gros paquet de données via un bus PCIe bien lent.

Ça c'était (c'est) le GPU de grand-papa. Ce qui est en train d'apparaître maintenant, notamment chez AMD (mais les autres suivent, y compris les éditeurs logiciels), ce sont des coeurs GPU intégrés au CPU, toujours vectoriels mais beaucoup pus généralistes, ayant résolu à peu près tous les points mentionnés ci-dessus. Ne reste plus que l'absence de pile d'appels, ce qui sera sans doute résolu dans une ou deux générations.

Donc oui on va faire de plus en plus appel au GPU, mais ce ne sera certainement pas avec du C.
* D'abord parce que personne ou presque n'a envie de programmer en C : peu productif, risqué, etc.
* Ensuite parce qu'écrire ton code dans deux langages, ça veut dire écrire plein de plomberie pour faire cohabiter les deux et beaucoup de redondance.
* Enfin parce que beaucoup d'algorithmes perdent de leur intérêt si tu dois préalablement transformer tes données d'un format vers un autre, et vice-versa au retour.

Sceptique ? Jette un coup d'oeil au projet Sumatra. C'est un gros effort d'AMD et d'autres pour programmer le GPU directement en Java (avec bien sûr des limitations concernant les parties à exécuter sur le GPU mais pas tant que ça).

Plus généralement tout ce problème s'inscrit dans la perspective du calcul hétérogène dans le nuage: autrement dit la capacité à exploiter des architectures spécifiques dans le nuage, tout en payant la plus petite taxe de virtualisation possible. Un acteur comme Microsoft mise pour ça sur un bytecode dont certaines propriétés (isolation mémoire, absence de deadlock avec l'extérieur, etc) sont prouvables (de façon à lever la taxe) et qui aura pour cibles de compilation tant des CPU que des GPU ou autres. Si ce bytecode sera vraisemblablement de plus bas niveau que celui de dotnet, je doute qu'on puisse y compiler efficacement du C. D'ailleurs MS développe un langage de plus haut niveau et plus sécurisé que le C mais d'assez bas niveau pour être dédié à la programmation système tout en tournant sur ce bytecode ; il serait destiné aux pilotes de péirphériques et au coeur du système.


Non. Mais coûteux, oui, tout comme l'ensemble shared_ptr + weak_ptr + allocateur par tas. Souvent moins en fait.


Non, pas des millions d'objets. D'abord parce qu'on n'a pas à visiter les anciens objets (génération 2 - il faudra seulement visiter les pages mémoire modifiées) ni les objets inaccessibles. Ensuite parce que la pile d'appels est en général assez compacte. Enfin parce que c'est un problème mémory-bound mais que les nouveaux objets sont tous dans le cache L3 ou inférieur.


Des algos de ce genre existent, oui, mais ils obligent à utiliser des formes de synchronisation à tel ou tel moment et ne sont donc pas forcément plus intéressants. Comme d'hab il n'y a pas de magie. A ma connaissance (mais je ne suis pas spécialiste) il est généralement plus rapide d'arrêter les threads (voire de les arrêter indépendamment pour les serveurs webs) mais de ne faire que le strict minimum à ce moment-là et reporter le reste de la charge à plus tard.

La tu confond largement multi-coeur et GPU.

Le premier c avoir N processeur et en java ou autre utiliser des threads et des sémaphores ou autre objet de synchronisation.
Pour certain problème c la seul solution pour d'autre il y a bcp plus puissant car sans utilisation de mécanisme de synchronisation de thread, cette solution est utilisé avec les shaders.
Pour les shaders tu N unité de calcul qui vont fonctionner de façon indépendante .
Quand un vertex shader travail sur un vertex il ne peut pas interagir avec un autre vertex shader en cour d'execution et c la ou est le gain car il y a pas de synchronisation.

Ce concept de parallélisation a un nom mais je m'en souvient pas.
En gros on a une tache A de préparation N tache en parallèle totalement indépendante et une tache B qui s’exécute une fois que tout est terminé, pour produire un resultat.
Ce genre de concept est par exemple idéal pour le tri fusion.

tache A séparation de la liste en deux.
tache en parallèle tri des deux liste (c du récursif )
tache B fusions des deux liste.


Ce genre de parallélisation nécessite un langage spécifique, en java c possible mais on ne peut pas garantir la non interaction des taches parallèles.
En plus l'architecture matériel qui permet ce genre de fonctionnement est bcp est plus simple qu'un multi coeur ce qui permet pour un même prix d'avoir bcp plus d'unité de calcul.

[JolyLoic]

Non, pas des millions d'objets. D'abord parce qu'on n'a pas à visiter les anciens objets (génération 2 - il faudra seulement visiter les pages mémoire modifiées) ni les objets inaccessibles. Ensuite parce que la pile d'appels est en général assez compacte. Enfin parce que c'est un problème mémory-bound mais que les nouveaux objets sont tous dans le cache L3 ou inférieur.

Juste un petit détail : Le C++ a un avantage dans cette situation : On génère globalement beaucoup moins d'allocations mémoire en C++ qu'en Java, car l’agrégation se fait à l'aide d'un seul emplacement mémoire, là où Java va faire deux allocations et un pointeur entre les deux (remarque : C'est aussi un avantage pour l'utilisation du cache et le préfetching).

[AliusEquinox]

Si COBOL est encore numero 1 dans le domaine de la finance, c'est du essentiellement au fait que s'il fallait tout réecrire dans un autre langage comme C++ (ou Java, mais il y a plus de réserve à son égard), le nombre de defaut augmenterait en fleche pendant une periode indéterminée. Se serait evidemment une catastrophe parce que les banques perdraient de l'argent.

De plus, si je puis dire, les developpeurs (tous langages confondus) developpent de plus en plus mal, pour être plus précis, la part des mauvais developpeur augmente considérablement dans la moyenne. Ce qui vous l'aurez deviner pousse les banques -- qui ont une frousse du risque monumentale (déformation professionelle tout ça tout ça) -- à être quelque peu pessimiste à l'égard de certains langages (Java où tu te cache ?! ).
Alors vous comprendrez, je l'espère, le raisonnement des banques : pourquoi utiliser un autre langage alors que COBOL est là ? pourquoi faire confiance a des nouveaux developpeurs alors que les developpeurs COBOL sont là depuis des décennies ?

[Uther]

Tout comme une JVM doit être présente sur toute machine cible pour le Java, mais oui, le fait que le langage ne soit pas multiplatforme est un défaut (il est tout à fait possible d'écrire du code portable cependant).

Certes mais c'est bien plus complexe car le C++ a beaucoup d'élément de base qui n'aident pas a aller dans ce sens, particulièrement les nombreux cas non déterminé de la spec, les type de taille variable, l'endianess, ... C'est un peu le reproche que je fait au C++ : c'est que les bons mécanismes sont généralement bien moins mis en valeur que les mauvais (généralement a cause de l'héritage du C).

Même une JVM ?

Théoriquement rien ne l’empêche, maintenant j'ai du mal a en voir l’intérêt.