Les VM garantissent effectivement comme en C qu'à la fin de ton programme, il n'y aura pas eu de perte de mémoire. Mais elles garantissent surtout, et contrairement au C, que la mémoire utilisée puis devenue inutile puisse être libérée ou réutilisée avant la fin du programme. En C si on a un memleak, on le garde jusqu'à la fin du programme. Pas terrible pour une appli serveur... Elles empêchent aussi que les erreurs de débordement classiques sont évitées : on a des exceptions au lieu d'un core dump.
Avant de bosser en entreprise je ne comprenais pas l'intérêt de laisser la gestion de la mémoire à une VM. Les perfs étaient en général moins bonnes que si on gère la mémoire soi même, et ça me paraissait plus relever de la flemme de gérer la mémoire que d'un besoin réel.
Depuis que je bosse, je m'aperçois que certains concepts de base échappent totalement aux développeurs qui bossent avec moi.
Je fais actuellement du J2EE et je ne connais personne qui soit capable ici de gérer la mémoire. Par exemple j'ai aidé à déboguer une lib JNI qui a été codée par des devs Java ne connaissaient pas le C++. Un exemple bien classique de ce que j'ai trouvé :
char *code = new char[2];
fonction_de_remplissage_qui_vient_de_la_dll(code); // cette fonction définissait, entre autres, les valeurs de char[0] et char[1]
conversion_char*_en_StringUTF8_pour_java(code);
Ici personne ne comprenait pourquoi ça plantait. Pour eux, on réservait un espace de 2 caractères, point. Ils passaient totalement outre le fait que la doc mentionnait que code devait être une "null terminated string". Sous MSVC en mode debug, évidemment ça fonctionnait, avec des caractères genre ÿ aléatoires avant la fin de la chaîne.
Ce genre de problème ne peut pas arriver dans une VM type Java parce que la mémoire n'est pas gérée par les développeurs.
Je vois plutôt ça comme un aveu d'impuissance : on pense que les développeurs basiques feront des erreurs. On n'a pas assez d'énergie pour rendre les développeurs meilleurs, donc on leur masque la complexité et on trouve un langage dans lequel ils ne peuvent pas faire ces erreurs.
[^] # Re: Pourquoi Mono ?
Posté par TortuXm . En réponse au journal Utiliser Mono sans peur. Évalué à 1.
Avant de bosser en entreprise je ne comprenais pas l'intérêt de laisser la gestion de la mémoire à une VM. Les perfs étaient en général moins bonnes que si on gère la mémoire soi même, et ça me paraissait plus relever de la flemme de gérer la mémoire que d'un besoin réel.
Depuis que je bosse, je m'aperçois que certains concepts de base échappent totalement aux développeurs qui bossent avec moi.
Je fais actuellement du J2EE et je ne connais personne qui soit capable ici de gérer la mémoire. Par exemple j'ai aidé à déboguer une lib JNI qui a été codée par des devs Java ne connaissaient pas le C++. Un exemple bien classique de ce que j'ai trouvé :
char *code = new char[2];
fonction_de_remplissage_qui_vient_de_la_dll(code); // cette fonction définissait, entre autres, les valeurs de char[0] et char[1]
conversion_char*_en_StringUTF8_pour_java(code);
Ici personne ne comprenait pourquoi ça plantait. Pour eux, on réservait un espace de 2 caractères, point. Ils passaient totalement outre le fait que la doc mentionnait que code devait être une "null terminated string". Sous MSVC en mode debug, évidemment ça fonctionnait, avec des caractères genre ÿ aléatoires avant la fin de la chaîne.
Ce genre de problème ne peut pas arriver dans une VM type Java parce que la mémoire n'est pas gérée par les développeurs.
Je vois plutôt ça comme un aveu d'impuissance : on pense que les développeurs basiques feront des erreurs. On n'a pas assez d'énergie pour rendre les développeurs meilleurs, donc on leur masque la complexité et on trouve un langage dans lequel ils ne peuvent pas faire ces erreurs.