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 gc . En réponse au message C'est quoi exactement, du code managé ?. É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