compilation /CLR

Bonjour tout le monde.

J'aimerais avoir plus de renseignement sur cette option.

Si j'ai bien compris, cela permet d'utiliser du code managé, de gérer la mémoire et d'autres choses qui ne sont pas très claires pour moi.

Je développe une application qui utilise de façon intensive la décompression de données multimédias. Est-ce que j'ai intérêt à désactiver cette option. Si oui ou non pourquoi?

De ce que j'ai pû lire sur le site de microsoft, désactiver cette option peu faire ralentir l'application sauf dans des cas très précis sur des architectures spécifiques. Mais je ne suis pas sur d'avoir tout compris.

J'aimerais votre avis sur la chose, (si possible bien argumenté). Merci.

PS: J'utilise visual C++.net 2003 version standard, ce qui veut dire que je n'ai pas le compilateur optimisé (il y est mais il est comme désactivé), j'utilise donc parfois VC++ toolkit, mais il me semble qu'une fois depuis mon visual, j'ai réussi à compiler du code avec l'option (/optimisé....) du moins je n'ai pas eu de message d'erreur, tout cela en recopiant les mêmes options que j'utilisais dans le toolkit vers mon visual!!!

Citation:

---

De ce que j'ai pû lire sur le site de microsoft, désactiver cette option peu faire ralentir l'application sauf dans des cas très précis sur des architectures spécifiques. Mais je ne suis pas sur d'avoir tout compris.

---

tu as lu ça ou ?
/clr permet de compiler / utiliser du code managé, c.a.d .Net. En ce qui concerne le code natif, mis à part quelques options imcompatibles, à rpiori je dirais que ça n'a pas d'incidence.

Ici:

http://msdn.microsoft.com/visualc/pr...q/default.aspx

Citation:

---

What are the performance implications of using managed code?
It depends. Purely managed code (no specific use of CLR data types) will generally run slower, but this is not always the case. For example, the CLR-targeted Quake II port runs approximately 5 to 15% slower on most platforms, but runs slightly faster on Intel Centrino Pentiums.

Microsoft recommends that developers selectively retarget portions of their applications to the CLR where it makes sense, and to tune the managed/unmanaged boundaries when and if performance issues arise.

---

En effet, je n'avais rien compris. C'est bien ce qui me semblait. C'est un peu plus lent avec cette option mais pas toujours.

Cette option n'est pas déterminante en elle même. Elle te permet d'écrire du code managé. Le code managé nécessite /clr pour être compilé (car basé sur des extensions au langages C++). Le code managé est plus lent que du natif. Le code natif n'est pas affecté.

Juste une petite précision, si tu ne fais pas de .Net, n'utilise surtout pas cette option :!:

J'ai eu quelque bugs sympas, avec Boost et à l'exécution seulement, lorsqu'elle était activée (par erreur). Et les messages d'erreur ne sont vraiment pas explicite.

VC++ 8 est censé améliorer la cohabitation C++ / C++ managé. Wait & see... 8)