Cette dénomination est utilisé dans la plateforme .NET pour désigner du code exécuté par la machine virtuelle, je crois. Je suppose que l'on peut dire que le java est du code managé aussi ?
Par exemple le C++ managé est du C++ qui sera executé sur la machine virtuelle .NET et qui peut donc faire appel facilement à des bibliothèques C++ natives et et accéder aux fonctionnalités de la plateforme .NET.
Je ne crois pas que ça ait un rapport avec la sécurité, mais là, je laisse la parole aux experts :).
On parle de sécurité mais pas dans le sens courant, c'est plutôt la "sûreté d'exécution" : on est un peu plus sûr que le programme fera ce qu'on attend de lui (et que s'il ne le fait pas cela causera moins de tord). Ça ajoute aussi à la sécurité proprement dite ceci dit, car les attaques par dépassement de tampon ou formattage de chaînes deviennent impossible.
Bon moi quand j'extrais le buzz de l'article ci-dessus, je trouve qu'il ne reste plus grand chose et c'est très comparable à Java : on note un progrès grâce au garbage collector qui enlève les fuites de mémoires et réduit les risques de plantage (mais comme en Java ils ont choisi de garder les NullPointerException - ça s'appelle NullReferenceException si j'en crois la doc en ligne), mais lorsqu'il parle de "exception handling, type safety, array bounds and index checking" ajoutés dynamiquement par le runtime, je ne vois pas trop ce que ça peut faire d'autre que "planter proprement" au lieu de segfaulter, comme en Java. Mais quelqu'un qui en connait plus long sur le CLR pourra peut-être apporter des détails supplémentaires ?
En tous cas pour répondre aux questions initiales :
- ça apporte des plantages plus "propres", plus facilement débuggables, plus proches de l'endroit du problème (une corruption mémoire dans un langage sans garbage collector peut induire un plantage plusieurs milliers de lignes de code plus loin)
- oui ça ralentit, en général non ce n'est pas un gros problème, mais tout ça dépend du type de programme et du besoin de vitesse de l'application (seuls l'OS et les applications de calcul ont un besoin crucial de vitesse)
- pour moi oui ce serait l'avenir car ça augmente grandement la qualité des programmes ; le problème c'est que sous Linux il n'existe pas d'environnement libre correct en code managé[1], celui qui s'en approche le plus c'est mono mais il y a l'énorme problème de la dépendance envers Microsoft et les brevets sur .NET ; un autre problème est l'attachement dogmatique des unixiens/linuxiens au C :)
[1] perl/python/ruby/etc ne qualifient pas parce que le code ne peut pas être compilé pour obtenir des performances proches du code natif comme cela peut être le cas avec Java ou .NET ; on pourrait citer cependant ocaml mais les langages non-impératif-et/ou-qui-ressemblent-pas-au-C ont bien du mal à décoller hors des cercles académiques
> oui ça ralentit
Pas forcément, regardes le langage D (http://www.digitalmars.com/d/index.html) et Ocaml: ils sont plutôt performant (http://shootout.alioth.debian.org/great/benchmark.php?test=all&lang=all&sort=fullcpu) et ils utilisent un ramasse miettes.
Un ramasse miette permet d'optimiser la gestion de la mémoire avec un seul code, un seul algorithme qui ne s'éxécute que de temps en temps. Le seul défaut est qu'on ne peut pas vraiment prédire quand ce qui peut entrainer des latences de temps en temps. Pour éviter cela D et Ocaml permette de le désactiver ou de gérer certaines parties de la mémoire manuellement.
# .NET
Posté par alberthier (site web personnel) . Évalué à 2.
Par exemple le C++ managé est du C++ qui sera executé sur la machine virtuelle .NET et qui peut donc faire appel facilement à des bibliothèques C++ natives et et accéder aux fonctionnalités de la plateforme .NET.
Je ne crois pas que ça ait un rapport avec la sécurité, mais là, je laisse la parole aux experts :).
[^] # Re: .NET
Posté par gc (site web personnel) . Évalué à 4.
On parle de sécurité mais pas dans le sens courant, c'est plutôt la "sûreté d'exécution" : on est un peu plus sûr que le programme fera ce qu'on attend de lui (et que s'il ne le fait pas cela causera moins de tord). Ça ajoute aussi à la sécurité proprement dite ceci dit, car les attaques par dépassement de tampon ou formattage de chaînes deviennent impossible.
Bon moi quand j'extrais le buzz de l'article ci-dessus, je trouve qu'il ne reste plus grand chose et c'est très comparable à Java : on note un progrès grâce au garbage collector qui enlève les fuites de mémoires et réduit les risques de plantage (mais comme en Java ils ont choisi de garder les NullPointerException - ça s'appelle NullReferenceException si j'en crois la doc en ligne), mais lorsqu'il parle de "exception handling, type safety, array bounds and index checking" ajoutés dynamiquement par le runtime, je ne vois pas trop ce que ça peut faire d'autre que "planter proprement" au lieu de segfaulter, comme en Java. Mais quelqu'un qui en connait plus long sur le CLR pourra peut-être apporter des détails supplémentaires ?
En tous cas pour répondre aux questions initiales :
- ça apporte des plantages plus "propres", plus facilement débuggables, plus proches de l'endroit du problème (une corruption mémoire dans un langage sans garbage collector peut induire un plantage plusieurs milliers de lignes de code plus loin)
- oui ça ralentit, en général non ce n'est pas un gros problème, mais tout ça dépend du type de programme et du besoin de vitesse de l'application (seuls l'OS et les applications de calcul ont un besoin crucial de vitesse)
- pour moi oui ce serait l'avenir car ça augmente grandement la qualité des programmes ; le problème c'est que sous Linux il n'existe pas d'environnement libre correct en code managé[1], celui qui s'en approche le plus c'est mono mais il y a l'énorme problème de la dépendance envers Microsoft et les brevets sur .NET ; un autre problème est l'attachement dogmatique des unixiens/linuxiens au C :)
[1] perl/python/ruby/etc ne qualifient pas parce que le code ne peut pas être compilé pour obtenir des performances proches du code natif comme cela peut être le cas avec Java ou .NET ; on pourrait citer cependant ocaml mais les langages non-impératif-et/ou-qui-ressemblent-pas-au-C ont bien du mal à décoller hors des cercles académiques
[^] # Re: .NET
Posté par bobefrei . Évalué à 2.
Pas forcément, regardes le langage D (http://www.digitalmars.com/d/index.html) et Ocaml: ils sont plutôt performant (http://shootout.alioth.debian.org/great/benchmark.php?test=all&lang=all&sort=fullcpu) et ils utilisent un ramasse miettes.
Un ramasse miette permet d'optimiser la gestion de la mémoire avec un seul code, un seul algorithme qui ne s'éxécute que de temps en temps. Le seul défaut est qu'on ne peut pas vraiment prédire quand ce qui peut entrainer des latences de temps en temps. Pour éviter cela D et Ocaml permette de le désactiver ou de gérer certaines parties de la mémoire manuellement.
[^] # Re: .NET
Posté par Ontologia (site web personnel) . Évalué à 1.
Si je comprend bien ça consiste à planter à l'endroit où est l'erreur et de préciser de laquelle il s'agit ?
Eiffel le fait, Lisaac aussi (bientôt) !
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.