salut a tous ,
je crois que ma question est dans le titre. j'arive pas à comprendre exactement ce point ; "code managé" "envirennement managé" 8O
à l'aaaaaaaaaaaaaaaide SVP :roll:
Version imprimable
salut a tous ,
je crois que ma question est dans le titre. j'arive pas à comprendre exactement ce point ; "code managé" "envirennement managé" 8O
à l'aaaaaaaaaaaaaaaide SVP :roll:
Tout ce qui est managé, c'est tout ce qui est géré par le Framework .NET
Donc un code managé, c'est un code compilé via un langage .NET (C#, VB.NET, etc...)
Quand tu compiles en dotnet, ton code n'est pas compilé en binaire directement mais dans un language intermédiaire.
Lorsque tu vas lancer ton exécutable, le CLR (Common Language Runtime) va traduire chaque partie de ton code en binaire au moment où tu en auras besoin dans l'application. Il y a donc un contrôle à tout moment par le CLR du code qu'il exécute.
La dénomination de code managé est elle seulement propre à .NET ? Il me semblait que java était aussi du code managé ?? :question:Citation:
Envoyé par Thomas Lebrun
Bonjour,
code managé ou code géré est le code répondant au CLI (Common Language Infrastructure).
Bye
Et y a-t-il une baisse de performance vis-à-vis des binaires ordinaires ?Citation:
Envoyé par Cardi
Ca c'est sûr mais ça a ses avantages non négligeables car tu améliores considérablement la sureté de tes programmes :Citation:
Envoyé par Eldacar
- Il n'y a plus de fuites de mémoire grâce au Garbage collector
- Vérification que les variables sont bien du type attendu
+ :Citation:
Envoyé par Cardi
- Sécurité d'accès au code au moment de l'exécution
- Possiblité de Reflexion en runtime
Il peut y avoir une baisse comme il peut ne pas y en avoir. En java, il y a HotSpot associé à la machine virtuelle qui va éventuellement recompiler en natif certaines parties du code lors de l'exécution (par exemple les parties les plus utilisées vont être optimisé et compilé en code binaire).Citation:
Envoyé par Eldacar
L'avantage par rapport à un compilateur classique est que la machine virtuelle sait exactement quelles sont les parties du code qu'il est nécessaire d'optimiser puisqu'il exécute lui même le code et peut faire du profiling en cours de route.
En dotnet le runtime compile automatiquement les parties de code en binaire et les stockent pour réutilisation si besoin est. pas besoin de profiling ;). Par contre la baisse de perf sera toujours présente à la premiere exécution d'une méthode car il y a compilation "Just-in time"Citation:
Envoyé par millie
Si je me rappelle bien je crois que le compilo JIT est encore plus futé que ça : il va même déterminer quelles sont les méthodes susceptibles d'être les plus utilisées et le plus rapidement afin de les compiler en natif le plus vite possible. Le tout est ensuite placer en cache pour les utilisations futures.Citation:
Envoyé par dev01
La baisse de perf est plutôt visible à cause du GC : vider le GC est une opération assez lourdes en ressources. Les dev C++ ont de gros problèmes pour palier les fuites de mémoires, nous on doit faire attention à ne pas bourrer le GC.
La facilité du GC amène donc aussi d'autres souçis. (Je suis d'accord que fasse à la gestion de la mémoire en C++, on est est plutôt "cool" :mrgreen: )
En traitement d'images (pour les grosses opérations) on recommande de bosser en "unsafe" : c'est une partie du code qui ne sera pas gérer par le GC (il ne manipulera pas ton objet) : tu bosseras donc avec des pointeurs, tu peux alors attaquer directement l'emplacement mémoire... Au prix bien sur de la sécurité (unsafe^^)
http://msdn2.microsoft.com/en-us/lib...b8(VS.71).aspx
http://msdn2.microsoft.com/en-us/lib...74(VS.71).aspx
Mais c'est à utiliser dans des cas vraiment très particulier.
Exactement. Mais le GC a été revu et corrigé avec le Fx 3.5 il me semble et les perf devraient être bien meilleureCitation:
Envoyé par Chubyone
( cf :
http://blogs.msdn.com/clyon/archive/...een-doing.aspx
)