J'imagine bien le bébé dont le lange change de type...Hop, lavable, hop en coton, hop jetable...
Le Top 20 des forums
Kevin Kofler (./3907) :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 :
Le Java est moins puissant que le C++
Kevin Kofler (./3909) :Tout d'abord, c'est plus un soucis de la VM de Sun/Oracle et de OpenJDK qui en a hérité que du langage en lui même. Il y a des langes avec GC qui gèrent leur mémoire de manière sensiblement différente. Cependant, contrairement à ton intuition, si tu ne consomme pas trop de RAM, la VM d'Oracle libère cependant la RAM bien avant d’atteindre le maximum. Ce qui est trompeur c'est que c'est vrai qu'elle ne libère pas immédiatement et si tu alloue souvent, tu va atteindre le maximum avant qu’elle ai libéré assez, et a ce point elle sera obligé de libérer en effet.
Le GC fait que tu dois fixer un seuil de mémoire arbitraire à partir duquel libérer la mémoire, donc tant que tu es en dessous du seuil, le programme en consomme de plus en plus sans rien libérer, et si tu le dépasses, plus rien ne marche (ça commence à passer tout le temps dans le GC et, si jamais ça sort de la boucle, ça finit avec une exception "Java heap space" ("exhausted", mais ce n'est pas écrit explicitement dans le message de l'exception)). Du coup, tu ne peux pas utiliser de manière efficace la RAM de ta machine: soit tu bouffes toute la RAM pour rien (seuil trop haut), soit le programme plante alors qu'il resterait plein de RAM dans la machine (seuil trop bas).
Kevin Kofler (./3909) :C'est vrai que les pauses du GC sont un vrai problèmes pour certains types d'application. Je peux témoigner, pour avoir développé des jeux en Java, Le GC était un problème qui revenait régulièrement.
Un autre gros inconvénient est que le GC bloque l'exécution régulièrement à des endroits difficilement prévisibles, ce qui non seulement rend le Java inutilisable pour toute application temps réel (Ce n'est pas par hasard qu'il y a un gros avertissement de Sun/Oracle de ne jamais utiliser la technologie Java dans un réacteur nucléaire, ce serait le prochain Tchernobyl!),
Kevin Kofler (./3909) :mais se remarque aussi dans la vie courante quand l'interface utilisateurs d'un logiciel freeze soudain pour une seconde ou deux parce que le GC a choisi de s'activer de nulle part.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.
Kevin Kofler (./3909) :Et le troisième gros inconvénient est que le GC fait que tu ne contrôles pas quand le finalisateur de l'objet sera appelé. (Du coup, les objets pour lesquels c'est important nécessitent un close() explicit qu'on risque d'oublier, et il y a ce hack de "try with resources" qui fait que finalement, ces objets s'utilisent de la même manière qu'un objet RAII en C++. Sauf que tu ne peux pas oublier d'appeler le destructeur en C++ alors que tu peux oublier d'utiliser "try with resources" ou d'appeler close() explicitement en Java.)Si on ne pouvait pas oublier d'appeler le destructeur en C++, ça se saurait.
Warpten (./3921) :Et le C# à la base n'est ni plus ni moins qu'une copie du Java.
le try-with-resources c'est ni plus ni moins qu'une copie du using de C#.
Warpten (./3921) :A ma connaissance, ça n’existe pas dans le VM J2SE standard. On peut juste essayer de forcer les GC aux moments les moins critiques pour réduire le risque qu'ils arrivent dans les sections critiques.
Au niveau des spurious wakeups du GC, en C# on a des mecanismes pour dire au GC de s'absenter pendant l'execution d'une routine je crois. En Java je connais pas.
Godzil (./3929) :Pas du tout, je voulais dire par là que ce sont des outils à destination des jeunes programmeurs ##rattrapage_aux_branches##Uther (./3927) :##pointgodzil##
mais il reste généralement plus performant et maintenable que les langes a typage dynamique
Uther (./3931) :Et c'est même le meilleur pour ça !
- La capacité de faire ce que fait mon langage préféré (mon langage préféré est très puissant)
)
Uther (./3931) :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.Kevin Kofler (./3907) :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 :
Le Java est moins puissant que le C++
- 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)
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.
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.
Les langages s'inspirent les un les autres et c'est tant mieux (sauf quand ils s'inspirent du JavaScript).LOL la parenthèse!
Kevin Kofler (./3933) :Sauf que, dans la majorité des cas, la surcharge d'opérateurs est plus un risque qu'un atout. C'est bien qu'un langage le permette s'il y a des besoins ; ce serait (très) dangereux que ce soit une norme vu ce que ça peut impliquer comme dangers pour la sécurité du code, surtout sur de gros projets ou lorsqu'il y a de la mutualisation de fichiers.
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.
Meowcate (./3937) :Pour être Brunni compatible, il faut qu'il n'y ait jamais deux fois la même couleur sur une même plage de mémoire, tu sais ?
mon éditeur m'affiche les 0 et les 1 de deux couleurs différentes.
Kevin Kofler (./3926) :Warpten (./3921) :Ce n'est pas final qui empêche la libération par le GC, mais l'utilisation dans le callback (qui maintient en vie la référence).
ils ont des problemes de memoire parce que y a du final partout pour reutiliser des variables dans des callback
Uther (./3931) :
Et le C# à la base n'est ni plus ni moins qu'une copie du Java.
Les langages s'inspirent les un les autres et c'est tant mieux (sauf quand ils s'inspirent du JavaScript).
Warpten (./3942) :Ce n'est plus le cas depuis Java 8, maintenant il suffit que la variable est "effectively final", c'est-à-dire qu'elle pourrait être déclarée final (mais tu n'es plus obligé de le mettre).
(tu ne peux pas referencer de variable du scope englobant sans final)
c'est l'equivalent d'un capture groupe pour une lambda en C++. J'en met jamais sinon.Bah non, final en Java a toujours été l'équivalent de const en C++, rien de plus ni de moins.
Nil (./3934) :Mais c'est à cause de ces boulets qui font n'importe quoi avec la surcharge d'opérateurs (dédicace spéciale à Boost qui les utilise entre autres pour représenter des grammaires en BNF
Sauf que, dans la majorité des cas, la surcharge d'opérateurs est plus un risque qu'un atout. C'est bien qu'un langage le permette s'il y a des besoins ; ce serait (très) dangereux que ce soit une norme vu ce que ça peut impliquer comme dangers pour la sécurité du code, surtout sur de gros projets ou lorsqu'il y a de la mutualisation de fichiers.
) que les développeurs du Java refusent de la proposer pour les cas où ce serait vraiment utile, comme l'arithmétique d'intervalles.
(enfin les vtable c'est standard mais rien n'empêche un compilo de faire autrement)Kevin Kofler (./3933) :si. C'était la dernière de la liste...
Ma définition de "puissant" est une que tu n'as pas citée
vince (./3957) :catch (...)
Tu es sur que ton langage sait gérer le catchall?
)pourquoi:
puts("Pourquoi?");
goto pourquoi;