Petite question concernant c#
Le fait d’avoir des “using” inutilies dans un fichiers .cs affecte-t-il les performances de l’application…?
A la compilation ca va ramer plus mais au runtime ca va pas changer, il charge les dll au dernier moment quand tu demande un type. Mettre un using pour le namespace en cours sert a rien et sera ignore. Cela dit pour du code propre… il vaut mieux eviter.
Il faut quand même préciser un truc.
Using n’est pas l’équivalent d’un import Java.
Alors qu’un import déclenche l’attachement du package et permet des références faiblement qualifiées, using ne crée pas de référence.
Ecrire using System.Web.UI.WebControls permet juste d’écrire TextBox tb = new TextBox(); au lieu de System.Web.UI.WebControls.TextBox tb = new System.Web.UI.WebControls.TextBox();
Il faut encore avoir une référence vers la bonne assembly (ici, System.Web.dll) pour que ça compile.
Autrement dit, C# a découplé le double rôle de import en using et référence.
Par conséquent, l’impact d’un using, même à la compilation, devrait être très faible.
Mais comme dit Glop, effectivement, des using qui ne servent à rien, c’est pas propre.
Excuse moi, Boudin, mais je suis pas sur de bien comprendrela différence
Je sais qu’en Java, il faut aussi mettre une “référence” au package lors de la compile (faut qu’il soit dans le classpath), sinon ça passe pas non plus.
Qu’entends-tu par référence ?
[quote]Excuse moi, Boudin, mais je suis pas sur de bien comprendrela différence
Je sais qu’en Java, il faut aussi mettre une “référence” au package lors de la compile (faut qu’il soit dans le classpath), sinon ça passe pas non plus.
Qu’entends-tu par référence ?[/quote]Exactement ma même chose, sauf qu’il s’agit pas d’un classpath. On donne explicitement les assemblies de référence au compilo,avec l’argument de compilation /r (ou visual le fait a ta place).
using permet simplement de réduire la quantité de code a taper, en disant au compilo : “Si le namespace est pas précisé, cherche l’identifieur dans celui-là”. C’est exactement la même chose en C++.
Merci pour les réponses.
Je ne parlais pas bien entendu de using vers le namespace en cours mais de using vers des namespaces de la même assembly.
Ma question étais principalement de connaitre l’impact performance et mémoire des using. Il semble qu’il n’y en a pas, donc c’est bien. En effet, je développe depuis quelques mois une plateforme backoffice et j’ai maintenant plusieures centaines de fichiers .cs qui contiennent certainement des using inutiles depuis que j’ai réorganisé et optimisé le code. Mais il ne semble pas urgent de nettyer précisément les using qui ne servent plus a rien dans la mesure ou cela prendrait beaucoup de temps.
Toutefois, j’aimerais quand meme le faire (pour des raisons de code propre). Existe-t-il un utilitaire permettant de détecter les using inutiles? fxCop le fait-il?
Ce message a été édité par bwets le 16/04/2004
[quote]using permet simplement de réduire la quantité de code a taper, en disant au compilo : “Si le namespace est pas précisé, cherche l’identifieur dans celui-là”. C’est exactement la même chose en C++.[/quote] Tout comme en java, avec un import ça “racourci” l’écriture des références aux classes.
Donc, y a pas de différence ?
[quote]Tout comme en java, avec un import ça “racourci” l’écriture des références aux classes. Donc, y a pas de différence ?[/quote]List le message de boudin Il explique la difference. C’est pas juste syntaxique en java.
Il me semble, y a quelques temps, avoir vu sur un blogs.msdn un lien sur un appli qui checkait tes sources et qui indiquait les “using” inutiles, qu’on pouvait donc virer parce que jamais pris en compte…
Si mes souvenirs sont bons, je crois même que les concepteurs de l’appli (à l’époque) ne donnait plus signe de vie…
A moins que cela dise qqch à Glop, en rentrant ce soir j’essaierais de retrouver ça… Mais je suis pas confiant…
[quote]A moins que cela dise qqch à Glop, en rentrant ce soir j’essaierais de retrouver ça… Mais je suis pas confiant…[/quote]Je pense que le mieux c’est de se tourner du cote de fxcop mais je suis pas sur qu’il fasse ca, et honnetement c’est pas tres utile de virer les using inutiles. En general ca se voir assez vite les plus “evidents” A moins de bosser sur un enorme projet, tu mattes le code de ta classe qui est pas gigantesque parceque t’as fait du code concis et modulaire
et tu vire ceux qui te sautent a la figure comme ayant rien a faire la. Si ta classe de gestion de calcul de vecteurs se met a utiliser System.Xml sans raison, te degages… Et pour les reste comme explique, contrairement a java, c’est purement syntaxique donc t’es peinard, t’as pas de pb d’alourdissement inutile.
[quote]List le message de boudin Il explique la difference. C’est pas juste syntaxique en java.[/quote] Mais je l’ai lu, et je vois pas la différence. C’est bien pour ça que je demande un peu plus d’explication… (éventuellement en PM si c’est pour expliquer un truc super évident que j’ai loupé à cause de mes lunettes trop sales
[quote][quote]List le message de boudin Il explique la difference. C’est pas juste syntaxique en java.[/quote]Mais je l’ai lu, et je vois pas la différence. C’est bien pour ça que je demande un peu plus d’explication… (éventuellement en PM si c’est pour expliquer un truc super évident que j’ai loupé à cause de mes lunettes trop sales
[/quote]Ha ok desole je croyais que t’avais rate. Ben en fait en C#, using c’est juste syntaxique ca te permet de pas ecrire le nom complet partout dans ta classe. En java le import ca a aussi un autre effet, ca va, a la compilation au moment du linker, charger tout ce qu’il y a dans les import pour compiler ta classe. C’est bad. En C# a la compilation pour que le linker prenne en compte ton assembly, il faut la specifier explicitement au compilateur au moyen du flag /r par exemple en ligne de commande. En Java import a un role syntaxique et un role de ‹ reference › pour le linker. Chai pas si c’est plus clair…
[i]
PS: J’emploi mal le terme de compilation dans ce post et je m’en sers comme d’un terme generique regroupant tout (parse/compilation/link) mais on me pardonnera hein [/i]
Ce message a été édité par GloP le 16/04/2004
[quote][quote]A moins que cela dise qqch à Glop, en rentrant ce soir j’essaierais de retrouver ça… Mais je suis pas confiant…[/quote]Je pense que le mieux c’est de se tourner du cote de fxcop mais je suis pas sur qu’il fasse ca, et honnetement c’est pas tres utile de virer les using inutiles. En general ca se voir assez vite les plus “evidents” A moins de bosser sur un enorme projet, tu mattes le code de ta classe qui est pas gigantesque parceque t’as fait du code concis et modulaire
et tu vire ceux qui te sautent a la figure comme ayant rien a faire la. Si ta classe de gestion de calcul de vecteurs se met a utiliser System.Xml sans raison, te degages… Et pour les reste comme explique, contrairement a java, c’est purement syntaxique donc t’es peinard, t’as pas de pb d’alourdissement inutile.[/quote]Ben… si, le projet EST énorme, un backoffice de titan, une dizaine de dll, presque autant d’outils satellites, plusieurs centaines de fichiers .cs. Justement parce que j’ai fait du code concis et modulaire, une classe par fichier (en général). J’ai déja fait de gros progres au niveau du nettoyage lorsque j’ai modulé le projet de base en plusieurs projets indépendants… et que j’ai changé le namespace de base en cours de route pour cause de changement de nom du projet (le premier nom etais déja utilisé par d’autres boites, ca me faisait chier de le laisser comme ca) … mais il en reste certainement.
Bon.
Mais si tu dis que ca n’alourdit pas (c’etais surtout du coté de la mémoire que je m’inquiétais dans la mesure ou le backffice est une appli web(mais pas asp.net)) alors je vais laisser comme ca en attendant que je trouve l’utilitaire désiré!
Je rebondis sur le sujet ( :bong: ) pour poser ma petite question :
ca sert à quelquechose de découper son namespace en sous-namespace ?
(ca veut rien dire ce que j’ai marqué, alors je détaille : 
j’fais un raytracer, et j’ai fais des namespaces RayTracer.Textures (contenant tous les types de textures), RayTracer.Maths, RayTracer.Engine, RayTracer.Objects, …
ca sert surtout pour coller à l’arborescence des répertoires, mais je ne sais pas s’il y a vraiment un gain en quoi que ce soit (à part à me faire chier à marquer des Using partout ou à mettre des Objects.xxx, etc).
Y’a un gain au niveau des perfs (par exemple… surtout en fait) ?
[quote]Je rebondis sur le sujet ( :bong: ) pour poser ma petite question :
ca sert à quelquechose de découper son namespace en sous-namespace ?
(ca veut rien dire ce que j’ai marqué, alors je détaille :
j’fais un raytracer, et j’ai fais des namespaces RayTracer.Textures (contenant tous les types de textures), RayTracer.Maths, RayTracer.Engine, RayTracer.Objects, …
ca sert surtout pour coller à l’arborescence des répertoires, mais je ne sais pas s’il y a vraiment un gain en quoi que ce soit (à part à me faire chier à marquer des Using partout ou à mettre des Objects.xxx, etc).
Y’a un gain au niveau des perfs (par exemple… surtout en fait) ?[/quote]Non, aucun gain en perf, mais un gain de clarté, ce qui est tout aussi important pur le developpeur! ca serait trop bete de ne pas utiliser un aussi bon systême de rangement!