Ca ne perturbe pas un programme bien écrit.
Bref, ca n'offre aucune garantie.
* int reste 32 bits, donc ça ne change pas.
jor. la norme ne défini strictement rien.
c'est que ta version 32 bits couvent un bug/crash, à corriger.
Non, juste que le langage C n'offre aucune garantie de comportement d'une implémentation à l'autre.
Sans parler du fait que tu es obligé d'avoir 2 binaires (voir n si tu as n architecture).
La seule garantie d'une VM c'est de libérer la mémoire à la fin, comme en C.
Non non et non. En C je peux très bien me balader n'importe où avec mes pointeurs dans mon espace mémoire et aller faire tout un tas de conneries qui vont influencer (négativement) l'exécution de mon programme et ajouter pleins de bugs.
je te laisse imaginer tous les problèmes de sécu potentiels, à commencer par les célèbres débordement de tampon. Y'a des techniques pour limiter la casse au niveau OS (comme c'est le cas dans le dernier noyau linux), mais il n'y a aucune garantie offerte.
Une VM garantie tous les accès mémoires, garantie qu'il y a bien un objet au bout et que tu es bien autorisé à y accéder.
Une VM peut gérer des droits d'exécution sur un code tiers au sein du même processus grâce à ce cloisonnement et cette maîtrise du bytecode exécuté, un programme en C peut faire à peu prêt tout et n'importe quoi dans son espace utilisateur. C'est pas pour rien que toutes les applets web utilisent un modèle de VM (Java flash, etc.)
Oui, j'ai jamais compris le truc génial de la gestion laissée à la VM, je suis sans doute vieux jeu.
Certains disent que la gestion mémoire est tellement importante qu'il faut mieux la laisser au développeur.
D'autres disent que la gestion mémoire est tellement importante qu'il faut mieux laisser ce travail à une machine.
[^] # Re: Pourquoi Mono ?
Posté par TImaniac (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 2.
Bref, ca n'offre aucune garantie.
* int reste 32 bits, donc ça ne change pas.
jor. la norme ne défini strictement rien.
c'est que ta version 32 bits couvent un bug/crash, à corriger.
Non, juste que le langage C n'offre aucune garantie de comportement d'une implémentation à l'autre.
Sans parler du fait que tu es obligé d'avoir 2 binaires (voir n si tu as n architecture).
La seule garantie d'une VM c'est de libérer la mémoire à la fin, comme en C.
Non non et non. En C je peux très bien me balader n'importe où avec mes pointeurs dans mon espace mémoire et aller faire tout un tas de conneries qui vont influencer (négativement) l'exécution de mon programme et ajouter pleins de bugs.
je te laisse imaginer tous les problèmes de sécu potentiels, à commencer par les célèbres débordement de tampon. Y'a des techniques pour limiter la casse au niveau OS (comme c'est le cas dans le dernier noyau linux), mais il n'y a aucune garantie offerte.
Une VM garantie tous les accès mémoires, garantie qu'il y a bien un objet au bout et que tu es bien autorisé à y accéder.
Une VM peut gérer des droits d'exécution sur un code tiers au sein du même processus grâce à ce cloisonnement et cette maîtrise du bytecode exécuté, un programme en C peut faire à peu prêt tout et n'importe quoi dans son espace utilisateur. C'est pas pour rien que toutes les applets web utilisent un modèle de VM (Java flash, etc.)
Oui, j'ai jamais compris le truc génial de la gestion laissée à la VM, je suis sans doute vieux jeu.
Certains disent que la gestion mémoire est tellement importante qu'il faut mieux la laisser au développeur.
D'autres disent que la gestion mémoire est tellement importante qu'il faut mieux laisser ce travail à une machine.