Discussion :

[am@123]

salut a tous ,
je crois que ma question est dans le titre. j'arive pas à comprendre exactement ce point ; "code managé" "envirennement managé"
à l'aaaaaaaaaaaaaaaide SVP

[Thomas Lebrun]

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...)

[Jérôme Lambert]

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.

[vladvad]

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...)

La dénomination de code managé est elle seulement propre à .NET ? Il me semblait que java était aussi du code managé ??

[Pilloutou]

Bonjour,

code managé ou code géré est le code répondant au CLI (Common Language Infrastructure).

Bye

[Invité4]

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.

Et y a-t-il une baisse de performance vis-à-vis des binaires ordinaires ?

[Jérôme Lambert]

Et y a-t-il une baisse de performance vis-à-vis des binaires ordinaires ?

Ca c'est sûr mais ça a ses avantages non négligeables car tu améliores considérablement la sureté de tes programmes :

• 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

[dev01]

Ca c'est sûr mais ça a ses avantages non négligeables car tu améliores considérablement la sureté de tes programmes :

• 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

+ :
- Sécurité d'accès au code au moment de l'exécution
- Possiblité de Reflexion en runtime

[millie]

Et y a-t-il une baisse de performance vis-à-vis des binaires ordinaires ?

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).

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.

[dev01]

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).

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"

[Chubyone]

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"

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.

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" )


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.

[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" )

Exactement. Mais le GC a été revu et corrigé avec le Fx 3.5 il me semble et les perf devraient être bien meilleure
( cf :

http://blogs.msdn.com/clyon/archive/...een-doing.aspx
)