Discussion :

[joseph_p]

Sinon pour le reste, il n'y a pas plus de 10-15% d'écart de vitesse entre Java et C++, ce n'est pas ce que j'appelle "lent".

Hum, tu as des sources pour ces chiffres ? En effet, non seulement c'est dur à évaluer comme chose, mais en plus ça bouge beaucoup avec les dernières JVM... Bref, je suis curieux de voir sur quoi s'appuie ce 10/15%...

Par ailleurs, suivant les cas, il ne faut pas oublier qu'un GC avantage par rapport à une gestion manuelle de la mémoire : il peut faire le ménage par bloc, ce qui est bien moins couteux que de le faire par objet.

Plus d'info par là http://www-128.ibm.com/developerwork...vaUrbanLegends ou là http://www.theserverside.com/news/th...hread_id=37146 .

Il ne faut pas oublier les optimisations à l'exécution que la JVM peut faire, notamment tout ce qui a trait au "hot spot" : http://java.sun.com/products/hotspot/whitepaper.html

[deneb]

Je n'ai pas de lien sous la main pour étayer ces chiffres, mais fais des recherches de bench comparatifs (Java/C++) et tu verra des chiffres dans ces eaux là.
De toute façon tout dépend du type d'application que l'on utilise pour le test.
Sur une application comme un serveur HTTP il n'y aura pratiquement aucune diff entre l'implémentation Java et celle en C++.
Par contre un prog de compression ou de traitement d'image pourra être facilement 2 voir 3 fois plus rapide en C++.

[adiGuba]

Ce qui le rend plus lent que le C++ (dans certains cas) c'est surtout la gestion de la mémoire...Et oui encore
Et c'est essentiellement dû à l'impossibilité d'accèder directement à la mémoire pour faire des lectures/copies de zones, à l'absence de tableaux de structures....et autres choses sympa qui permettent d'aller vite en C/C++.
Sinon pour le reste, il n'y a pas plus de 10-15% d'écart de vitesse entre Java et C++, ce n'est pas ce que j'appelle "lent".

Je ne pense pas que la gestion de la mémoire du GC soit un des points faible de Java.
Bien sûr il reste un obstacle pour le temps-réel. Mais ces petites optimisations (calculs sur les pointeurs) font gagner que si elles sont utilisée de manières abusives, ce qui est rarement le cas dans une application standard...


Quand au 10-15%, je pense qu'ils peuvent être dans les deux sens selon les cas de figure...

- Possibilité de l'activer/désactiver. Pourquoi? Je me base sur du J2ME par exemple. Le J2ME est très differet du J2SE car il faut gerer les ressources quasiment à l'octet près. Imaginez que vous devez charger 3 images (decors, sprits, etc...) et que ces 3 images arrivent juste à la limite de la place disponible. Le passage du GC fait augmenter de manière discrete la quantité de mémoire utilisée. Discrète, mais assez pour tout faire planter. Résultat --> Une jolie OutOfMemeryException. Si on pouvais désactiver le GC, cela ne se produirai pas, et on pourrai à la limite gerer nous même la mémoire comme en C.

Je n'ai pas de connaissance de J2ME (version Mobile pour ceux qui en saurait encore moins que moi), mais je ne vois pas en quoi l'absence de GC pourrait te venir en aide si tu utilises plus de mémoire qu'il n'y en a de disponible...

- possibilité de controler son passage : Encore un exemple J2ME (meuh nan j'abuses pas ^^). Chargement des ces 3 images, puis désinstanciation. Appel de system.gc(), puis attente de 5sec, puis appel de system.gc(), puis attente de 5sec, puis...etc... puis chargement d'une 4ème image --> OutOfMemoryException ! Pourquoi ? Tout simplement car l'appel de la méthode System.gc() ne force pas le gc à passer, mais lui dit qu'il PEUT passer. Dans notre cas, il n'est pas passé.

C'est vrai que System.gc() ne force pas le GC à passer, mais généralement faire suivre cela par une pause dans le thread courant (Thread.yield() par exemple) peut suffire...

Quand à l'OutOfMemory, elle ne survient normalement qu'après que le GC ait tenté de libérer tout ce qu'il lui était possible...

a++

[deneb]

Peut être qu'une simple méthode pour forcer le GC à libérer une instance imédiatement suffirait à contenter tout le monde.
Ceux qui ne veulent pas s'emmerder (en attendant les emmerdes ) continueraient comme avant...et les autres pourraient gérer proprement leurs désallocations.

[deneb]

Je ne pense pas que la gestion de la mémoire du GC soit un des points faible de Java.

Là c'est pas le GC qui est un problème, mais l'impossibilité de d'accéder directement à la mémoire.
Ce qui me manque le plus c'est les tableaux de struct...infiniment plus performants et économes en mémoire que des ArrayList de pointeurs vers des instances...

[zais_ethael]

Est-ce réellement un avantage ? En quoi ?

• Temps d'exécution ? Sûrement pas !
• Temps de dev ? j'en doute.
• Fiabilité ? D'expérience non...pas mieux qu'en C++.

Temps d'éxécution = tu sais très bien que non, mais avec la vitesse des ordinateurs de maintenant une grande partie des programmes n'ont pas besoin d'une vitesse subliminique (à part les jeux et certains autres - pour ca C++ imbatable).
Temps de dev et fiabilité = lis mieux ce qui est marqué en dessous. Comme je l'ai dit, C++ n'est pas 100% orienté objet (polymorphisme impossible à moins de prévoir sa programmation rien que pour ca + pas toujours facile à gérer et il faut bien connaitre) tandis que le java l'est (polymorphisme toujours possible à moins de mettre des classes/méthodes en final). Je répondrais donc par une question: mets tu en doutes l'utilité de l'orienté objet pour ce qui est de rendre les programmes plus rapides à programmer et plus fiables ou penses tu qu'il y a un autre moyen d'arriver au même résultat avec une gestion de la mémoire différente? Dans ce dernier cas j'aimerais savoir quoi.

[Brogomil]

Je n'ai pas de connaissance de J2ME (version Mobile pour ceux qui en saurait encore moins que moi), mais je ne vois pas en quoi l'absence de GC pourrait te venir en aide si tu utilises plus de mémoire qu'il n'y en a de disponible...

Je ne suis pas trop pour un GC entre autre pour la raison suivante :
comme on ne controle pas le moment ou le GC libère la mémoire, sur des systemes ayant peu de memoire (comme un appareil mobile, ou une puce) il se peut qu'a un moment, on ai decidé de libérer cette memoire pour l'utiliser pour autre chose, mais cette place n'est pas forcement libérée... au moment ou on appelle le destructeur. et c'est a ce moment qu'on a un out of memory.

de plus, si je ne m'abuse, le GC libere juste la memoire, mais ne la range pas, cad, on a 20 "cases" a liberer, et bien si le GC voit que la case 3 et la 7 sont liberable, il va effectivement libere mais si plus tard on a besoin de 2 cases contigues, pour reorganiser cela, c'est plus dur sans acces direct a la memoire.

J'ai cru effetivement lire qu'il y avait une methode en dotNET pour collecter, et donc vider la collecte précédente. mais je ne suis pas sur de cette info

[FremyCompany]

C'est à dire ? Tu peux être plus précis ?

Oui, bien sûr, voici un code (VB+Pseudo C#) qui devrait permettre d'y voir plus clair :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
REM ' est le commentaire OneLine en VB (REM est aussi valide)
REM // est le commentaire OneLine en C#, ...
Public Class MyClass 'public class MyClass { 
    Public Sub New() 'public MyClass {

    End Sub '}

    Protected Override Sub Finalize 'protected override ~MyClass {
         MyBase.Finalize() '// ?
    End Sub '}

    Public Sub DeleteFromMemory() 'public void DeleteFromMemory() {
        Me.Finalize() '// ?
        System.GC.SuppressFinalize(Me) 'System.GC.SupressFinalize(this);
    End Sub ' }
End Class '}

REM Utilisation
REM Dim Obj as New MyClass() 'MyClass Obj = new MyClass();
REM Obj.DeleteFromMemory() 'Obj.DeleteFromMemory();

[soad]

Hello tout le monde..

Ce sujet à l'aire très intéressant et je n'ai pas eu encore le temps de tout lire !

Je sais pas si sa a déjà été dit mais un j'avais lu une fois un document qui disait qu'un programme utilisant un GC était généralement plus rapide que si c'est le programmeur qui s'occupe de la mémoire ! Je parle pour les moyennes et grande application !

De plus y a beaucoup moins de risque de fuite de mémoire !!! Alors pkoi s'en priver !!!!

[FremyCompany]

J'ai cru effetivement lire qu'il y avait une methode en dotNET pour collecter, et donc vider la collecte précédente. mais je ne suis pas sur de cette info

Je confirme.

Pour plus d'informations sur le GC de DotNet :

• Membres de System.GC
• System.GC : Exemple simple d'utilisation

[deneb]

Temps d'éxécution = tu sais très bien que non, mais avec la vitesse des ordinateurs de maintenant une grande partie des programmes n'ont pas besoin d'une vitesse subliminique (à part les jeux et certains autres - pour ca C++ imbatable).

Quand tu fais du client-serveur, la partie cliente peut effectivement se satisfaire d'une vitesse d'exécution moyenne, mais le serveur lui ne peut pas.
Si tu perd 25% de vitesse à cause du langage tu dois dimensionner ton infra avec 25% de puissance en plus...
Plus de machines à acheter, plus de maintenance...etc.

Temps de dev et fiabilité = lis mieux ce qui est marqué en dessous. Comme je l'ai dit, C++ n'est pas 100% orienté objet (polymorphisme impossible à moins de prévoir sa programmation rien que pour ca + pas toujours facile à gérer et il faut bien connaitre) tandis que le java l'est (polymorphisme toujours possible à moins de mettre des classes/méthodes en final).

Le temps de dev est très inférieur en Java (par rapport à C++), mais certainement pas grâce au GC. C'est la richesse des API qui permet d'avancer très vite sur des sujet généralement généralement difficiles à traiter en C++ (Multithreading, mutex, ...). Le design du langage (mécanismes d'héritage, polymorphisme, précompilation...) joue peu sur le temps de dev ou la fiabilité.
En fait la fiabilité d'une application est essentiellement liée à la rigueur des "procédures" utilisées par l'équipe de dev.
Le GC ne permet pas de gagner du temps de dev. Ecrire un delete pour chaque new ne prend pas de temps.
Les tenants du GC disent qu'un développeur moyen fera moins d'erreur qu'en gérant la mémoire à la main à la sauce C++. Le pb c'est que ce même dévelopeur moyen, se croyant libéré de tout pb de gestion de la mémoire grâce au GC ne fera plus du tout attention...avec des conséquences identiques.

Je répondrais donc par une question: mets tu en doutes l'utilité de l'orienté objet pour ce qui est de rendre les programmes plus rapides à programmer et plus fiables ou penses tu qu'il y a un autre moyen d'arriver au même résultat avec une gestion de la mémoire différente? Dans ce dernier cas j'aimerais savoir quoi.

Voir au dessus. Je ne remet pas du tout en cause les langages à Objets qui sont très performants sur de gros projets.
Mais pour une bonne gestion de la mémoire, rien ne vaut deux hémisphères en bon ordre de marche.
En fait ce qui me manque c'est juste une vrai méthode : System.gc.delete(ref);

[Luc Hermitte]

Rapidement, quelques mauvais souvenirs de C++ :
- mauvaise allocation : taille d'un objet dépassant sa taille allouée. Conséquence : l'objet débordait sur un autre pour fonctionner. Du coup l'objet en partie écrasée ne fonctionnait plus bien. On a cherché pendant des heures ce qui n'allait pas dans notre code sur ce sacré objet (une simple boîte aux lettres) avant de comprendre. Erreur que je préfère éviter à l'avenir !

J'imagine que tu parles de tableaux. Je ne vois pas trop comment (hors hacks tout pourris) faire des dépassement sur de simples objets et autres structures.
Je ne vois pas le rapport avec le garbage collector. Quand on fait des buffers owerflow, le GC ne va rien changer. Un algo faux reste faux quelque soit le langage. Par contre, les structures tableau d'un langage ou d'un autre vont pouvoir réaliser des vérifications statiques ou dynamiques. En C++, tu as de quoi faire avec std::string et std::vector. Il est possible de rajouter simplement des éléments, et de payer une vérification de bornes si on le désire, même en mode release, en utilisant leur fonction membre at() plutôt que l'opérateur [].

Ce ne fut que sur des programmes simples... Je ne parle pas du dépassement de pile, qui certes ne m'est jamais arrivé mais m'a l'air fort fréquent et porte ouverte à bien des attaques...

Cela fait un bail que je n'ai plus saturé ma pile ; j'étais jeune, et c'était en Turbo Pascal sous DOS sur un 80286. De nouveau, je ne vois pas le rapport avec le GC qui travaille sur quelque chose qui s'apparente plus au tas qu'à la pile. Pars sur une boucle récursive infinie si tu veux la saturer.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
void f(int p_i) {
    int i = p_i + 1;
    affiche(i);
    f(i);
}

A suposer que le Java soit immusé, cela n'a aucun rapport avec le GC.

Il y a un point qui m'a toujours chagriné avec les garbages collectors, c'est la perte des Destructeurs.

Ce n'est pas une caractéristique de tous les GC. Le GC de .NET fait un bien meilleur boulot que celui de Java de ce côté là en permettant de distinguer libération (qui doit rester indéterministe je crois) et destruction qui peut être rendue déterministe. Et si les discussions pour avoir un GC dans le C++09 aboutissent, je doute qu'ils renoncent aux destructions déterministes comme cela.

<pinaillages HS, suite aux remarques de zais_ethael>
PS: Java n'est pas 100% objet (vive les types primitifs), et le 1.5 l'est encore moins qu'avant (vive les generics qui sont les représentants d'un autre polymorphisme, même s'il ne s'agit que d'un sucre syntaxique dans le cas du Java). C++ n'est pas 100% objet, et j'en suis bien content. Mais. 1- ce n'est pas le débat. 2- ce n'est pas le plus important dans un projet.

PPS: ce n'est pas parce que l'on peut supplanter une fonction membre que cela a du sens dans le paradigme objet. Une liste ne fera jamais une bonne classe de base pour définir une liste triée. On n'a pas déjà eu cette conversation tous les deux ?
</>

[adiGuba]

Ce n'est pas une caractéristique de tous les GC. Le GC de .NET fait un bien meilleur boulot que celui de Java de ce côté là en permettant de distinguer libération (qui doit rester indéterministe je crois) et destruction qui peut être rendue déterministe.

Je pense que c'est surtout une différence de philosophie.

D'après ce que j'ai compris la méthode System.GC.SuppressFinalize() permet simplement d'indiquer au GC ne ne pas "finalizé" l'objet car on l'a déjà fait. Donc on "détruit" bien l'objet, mais on ne le libère pas de la mémoire (c'est le GC qui s'en chargera).

Donc cela donnerait en C# (excusez-moi d'avance si je me trompe) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
MyObj Obj = new MyObj();

// Traitements ...

Obj.Finalize();
System.GC.SuppressFinalize(Obj);

En Java on considère que le GC ne devrait se charger que de la libération de la mémoire. Tout le reste (libération des resources systèmes : fichiers, socket, etc.) doit être fait explicitement par le développeur. On a donc généralement une méthode close() à appeller à la fin du traitement. On écrirait plutôt quelque chose du style :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
MyObj obj = new MyObj();
try {

    // Traitements ...

} finally {
    obj.close();
}

La méthode finalize() n'est qu'un garde-fou, et contient généralement un code du style :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
if (isNotClosed) {
     this.close();
}

On se retrouve à peu de chose près dans le même cas de figure...

Et si les discussions pour avoir un GC dans le C++09 aboutissent, je doute qu'ils renoncent aux destructions déterministes comme cela.

Un GC dans le C++ ! Intérressant !

<pinaillages HS, suite aux remarques de zais_ethael>
PS: Java n'est pas 100% objet (vive les types primitifs), et le 1.5 l'est encore moins qu'avant (vive les generics qui sont les représentants d'un autre polymorphisme, même s'il ne s'agit que d'un sucre syntaxique dans le cas du Java).

Je suis d'accord sur le fait que Java ne soit pas 100% Objet (mais quel langage l'est vraiment ?), mais je ne vois pas en quoi le 1.5 l'est encore moins ???

a++

[kawa]

En fait ce qui me manque c'est juste une vrai méthode : System.gc.delete(ref);

Hum, il y a de l'idée. Mais, si l'on pouvait forçer le GC à récolleter unitairement les objets ça serait problématique. Je m'explique: d'une part on ne libère pas UN objet mais potentiellement une grappe d'objet, et d'autre part un des travers qui en découlent directement est une segmentation plus élevée de la mémoire.

Personnellement, j'opterai plutôt pour une méthode collecte rapide System.gc.fastCollect(); ou mieux (mais là je rêve) System.gc.fastCollect(CollectConstraints); qui permettrait de spécifier quelques contraintes lors de la collecte (temps d'exécution max, mémoire mini à récupérer, etc.)

[adiGuba]

Hum, il y a de l'idée. Mais, si l'on pouvait forçer le GC à récolleter unitairement les objets ça serait problématique. Je m'explique: d'une part on ne libère pas UN objet mais potentiellement une grappe d'objet, et d'autre part un des travers qui en découlent directement est une segmentation plus élevée de la mémoire.

Ce pourrait être utile dans le cas d'un comptage simple de référence, en particulier pour les variables locales temporaires et ainsi éviter un peu de travail au GC (le GC n'aurait pas à "surveiller" la référence)...

Je viens de tomber sur cette RFE qui propose quelque chose de similaire en proposant la possibilité de déclarer des variables locales de la manières suivantes :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Object foo = new transient Bar();

Le transient indiquant que la durée de vie de l'objet ne dépassera pas celle de la méthode appellante. Cela impliquerait une destruction + libération de l'objet à la fin de la méthode ou du bloc (comme en C++).

Seulement cela demande beaucoups de modification, car les méthodes devront être adapté pour indiquer si elles acceptent des objets "transient" ou pas... et finalement cela compliquerait beaucoups de chose pour avoir du code sécurisé...

a++

[divxdede]

Il y a eu des remarques interressantes.

Nottament le ramassage d'un graphe de references entier (par bloc). En effet ce procédé est trés efficace par exemple pour un serveur J2EE. Puisqu'une fois que le serveur à atteint son rythme de croisière la taille du tas ne bouge "quasiment" plus et la libération mémoire par le GC deviennent trés rapides (idem pour les allocations). Car la JVM conserve la place "inutilisé" dans le tas. Et le GC évite effectivement une trop grande ségmentation (et donc réutilisation plus efficace de la place libre dans le tas).

Maintenant la remarque du J2ME m'a troublé, car effectivement dans le domaine de l'embarqué un GC() peut devenir pénible j'en conviens. Il y a 6 ans j'ai joué (en stage) sur un produit embarqué qui possédait quelques 100 de Ko de ROM et quelques Ko de RAM. A cette époque nous n'aurions pas aimé ne pas controler la mémoire à l'octet prêt.

Mais maintenant même les produits embarqué possédent plusieurs Mo (ca à bcp évolués en 6 ans) mais je pense que la gestion de la mémoire reste un élément critique.

Donc mon bilan est le suivant:

Domaine d'application où le GC est une force
- Application J2EE (execution de longue durée)
- Application StandAlone

Domaine d'application où le GC est néfaste ou problèmatique
- J2ME (produits embarqués)
- Produits à contrainte Temps Réel

[nyal]

Bonjour,

Vous parlez de performances, rapidité de développement, focalisation sur le code métier. J'aime bien prendre l'exemple python. (ça pourrait être java)

Python dispose d'un gc comme java, .net. Les performances de python sont très acceptable. Cependant, si on souhaite des meilleurs performances sur un bout de code, on peut utiliser swig. (ça marche pour de nombreux langages dont java)
Vous avez votre bout de code C/C++ pour:
- des raisons de performances
- du temps réel
- reprendre une bibliothèque existante

Il y'a des inconvénients:
- apprendre à utiliser swig
- "complexification" en ajoutant un langage

J'aime bien ce principe. Plus on se situe haut, plus on risque d'avoir des pertes. Mais il y'a la possibilité de "redescendre".

PS: quand je développais en C/C++, je me souviens des problèmes de debug sur des programmes complexes avec thread, mutex, semaphores, condition... Même avec efence, valgrind, gdb... c'était des fois très dur de situer le problème. On peut être le meilleur développeur du monde et avoir des fuites mémoires. (fuites qui créent des bugs aléatoires des fois)

[zais_ethael]

Quand tu fais du client-serveur, la partie cliente peut effectivement se satisfaire d'une vitesse d'exécution moyenne, mais le serveur lui ne peut pas.
Si tu perd 25% de vitesse à cause du langage tu dois dimensionner ton infra avec 25% de puissance en plus...
Plus de machines à acheter, plus de maintenance...etc.

Plus de machine à acheter = plus de sous, plus long de temps de dev = plus de sous, faut juste savoir trouver le compromis. Et puisqu'il est justement question de maintenance, j'aimerais justement dire que le C++ est très mauvais pour ca, contrairement au java (haaa, le refactoring), alors que la maintenance est justement ce qui engendre le plus de frais sur le long terme.

Le temps de dev est très inférieur en Java (par rapport à C++), mais certainement pas grâce au GC. C'est la richesse des API qui permet d'avancer très vite sur des sujet généralement généralement difficiles à traiter en C++ (Multithreading, mutex, ...). Le design du langage (mécanismes d'héritage, polymorphisme, précompilation...) joue peu sur le temps de dev ou la fiabilité.

Tu crois qu'il y a plus d'apis pour java? Au contraire, je dirais qu'il y en a au moins autant, probablement plus, en C++. Mais c'est justement la qu'on voit l'une des plus grosses différences. Le choix des bibliothèques en C++ est très délicat. Pour 10 librairies de sockets on peut très n'avoir la possibilité d'en utiliser aucune tout ca parcequ'il existe tellement de facons de programmer, tellement de point de vue différent sur, nottament, la gestion de la mémoire et les techniques pout faire du polymorphisme (ou pas), qu'on est très restriends dans ses choix. En java je ne dirais pas qu'une biblio toute mal foutue et aux trois quarts buggée pourrait être utilisée dans un programme pro mais "presque". Et ce ne serais-ce que parcequ'il n'y a pas 36 façons de concevoir une architecture.

[mat.M]

Aute chose: le garbage collector n'est pas forcément ce qui rend le java lent, il y a d'autres facteurs. Nottament le fait que ce ne soit pas un langage compilé. La seule façon de vérifier serait de faire des tests comparatifs sur des langages complilés implémentant aussi un garbage collector. Je n'en connais que deux: les java compilé avec GCJ et le D. Mais l'un et l'autre sont assez peu utilisés, donc moins soutenus et donc peut être moins au point et moins rapides.

Tout dépend comment Sun Ms a bati la JVM et les spécifications de cette JVM.
Si pour n'importe quelle opération il y a des controles en interne pour déterminer s'il y a exception il ya de chances qu'à l'exécution le programme en Java soit lent

[deneb]

plus long de temps de dev = plus de sous, faut juste savoir trouver le compromis.

Temps de dev, temps de dev ...
Un GC ne fait rien gagner du tout en temps !

Et puisqu'il est justement question de maintenance, j'aimerais justement dire que le C++ est très mauvais pour ca, contrairement au java (haaa, le refactoring), alors que la maintenance est justement ce qui engendre le plus de frais sur le long terme.

Ouaih enfin la maintenabilité d'un code est avant tout liée au respect strict de règles de développement adaptées au domaine.
J'ai vu de très gros prog C++ extrèmement faciles à maintenir...et des bouzes infame en Java...et vice versa.

Tu crois qu'il y a plus d'apis pour java? Au contraire, je dirais qu'il y en a au moins autant, probablement plus, en C++. Mais c'est justement la qu'on voit l'une des plus grosses différences. Le choix des bibliothèques en C++ est très délicat. Pour 10 librairies de sockets on peut très n'avoir la possibilité d'en utiliser aucune tout ca parcequ'il existe tellement de facons de programmer, tellement de point de vue différent sur, nottament, la gestion de la mémoire et les techniques pout faire du polymorphisme (ou pas), qu'on est très restriends dans ses choix. En java je ne dirais pas qu'une biblio toute mal foutue et aux trois quarts buggée pourrait être utilisée dans un programme pro mais "presque". Et ce ne serais-ce que parcequ'il n'y a pas 36 façons de concevoir une architecture.

Il y a effectivement des quantités d'API C++, beaucoup plus qu'en Java !
MAIS ce ne sont pas des API standard et c'est ça qui fait toute la différence.
En Java, tu prends le JDK tout est là ou presque, tu te pose pas 50 mille questions avant de commencer. En C++ tu passe ton temps à tourner en rond entre : recherche/apprentissage/tests...recherche/apprentissage/tests...
Et finalement chéquier...car la seule API valable est toujours hors de prix !
Ou alors (très souvent) tu prends ton clavier, ton courage à deux main et tu te fais ta lib perso.