Uther (./3931) :

Kevin Kofler (./3907) :
Le Java est moins puissant que le C++

La phrase que l'on voit typiquement quand on parle de langage de programmation, qui n'a aucun sens, ou du moins un sens très différents suivant les personnes :
- La capacité de faire des chose en peu de lignes de codes (Perl est tès puissant)
- La capacité de faire de la métaprogrammation avancée (LISP est très puissant)
- La capacité de faire du code dégeu qui a l'air de marcher ( JavaScript est très puissant)
- La capacité de faire un code dont on a une idée de comment il va être compiler (C est très puissant)
- La capacité de faire des choses avec un minimum d'apprentissage (Go est très puissant)
- La capacité de faire ce que fait mon langage préféré (mon langage préféré est très puissant)

Ma définition de "puissant" est une que tu n'as pas citée: la richesse en fonctionnalités du langage. Par exemple, le C++ permet la surcharge d'opérateurs, le Java ne la permet pas. Du coup, si on essaie par exemple de faire de l'arithmétique d'intervalles en Java (ce qu'on fait couramment dans l'équipe dans laquelle je travaille), le code devient vite totalement imbitable dès qu'on a une formule non-triviale. En C++, on peut utiliser la notation habituelle.

Par contre, les freeze de l'IHM sont rarement un problème du au GC en lui même mais plutôt à une mauvaise utilisation des bibliothèques IHM, particulièrement Swing qui exigent de travailler d'une manière particulière qui est souvent mal respectée. Les appli Java qui respectent les règles n'ont pas ce genre du problème.

Le fait que Swing ne permet pas de synchroniser l'IHM si on travaille dans le thread de l'IHM (contrairement à tous les autres frameworks d'IHM que j'ai utilisés jusqu'à présent: VB a DoEvents, Delphi a Application.processMessages, Qt a QCoreApplication::processEvents) est aussi un problème. Cela oblige à utiliser les threads, mais comme Swing n'est pas thread-safe et donc l'IHM ne peut être manipulée que dans le thread de l'IHM, tu te retrouves avec des problèmes de synchronisation. Du coup, certains développeurs préfèrent éviter et accepter les freezes.

Mais les freezes dus au GC existent aussi. (Il suffit de cliquer sur le graphique de consommation de mémoire dans NetBeans pour forcer un GC pour s'en rendre compte, l'IHM freeze immédiatement si tu fais ça.)

Si on ne pouvait pas oublier d'appeler le destructeur en C++, ça se saurait.

Certes, si tu utilises new, tu peux leaker l'objet, et du coup le destructeur ne sera pas appelé non plus. Mais si tu manages correctement ta mémoire, tu n'as pas ce problème.

Une méthode est la méthode RAII, où tu n'appelles jamais new, mais construis tout sur la pile. Si un objet est trop gros pour la pile, tu construis un smart pointer sur la pile, et celui-ci s'occupe d'allouer et libérer l'objet pointé comme s'il était sur la pile. Cela dit, si tu as besoin de retourner un objet alloué d'une fonction, tu dois du coup retourner un smart pointer adapté et faire attention à ne pas leaker celui-ci, donc les smart pointers ne résolvent pas tous les problèmes. Il faut quand-même savoir ce qu'on fait, contrairement à un langage à base de GC.

Les langages s'inspirent les un les autres et c'est tant mieux (sauf quand ils s'inspirent du JavaScript).

LOL la parenthèse!