pikti a écrit :
bein comprend toujours pas bien, doit être fatigué
edit: je veux dire je ne vois pas l'optimisation là-dedans
dans l'exemple ci-dessus l'initialisation à null ou autre ne sert d'ailleurs à rien, le mieux serait d'initialiser directement avec la bonne valeur
edit: ce qui est plus performant en .net 1.1 ou 2.0 (l'initialisation au moment de la déclaration plutôt que le faire en 2 fois comme ci-dessus)
|
c'est pas une question d'optimisation, c'est une question de propreté. je n'ai aucune info quand aux différences éventuelles de performance (ceci dit, le string.Empty ca effectivement créer une zone en mémoire, réutilisable par le GC alors qu'un null va retarder au plus tard possible la création de l'objet).
sinon, pour le coup du .Length() pour déterminer si tu as la chaîne vide, je ne suis pas convaincu.
en tout cas, le compilateur de VS 2005 n'est pas de cet avis : il préconise un == sur string.Empty quand on active les hints d'optimisation (feature de la version architect machin truc à 10000 ).
pour le coup de l'init à string.Empty(), idem, c'est le compilo qui me l'a dit, j'ai pas cherché à décortiquer les articles de 50 pages qu'il te donne comme raisons avec.
dans tous les cas, c'est bien plus propre.
à noter enfin que si tu fais ça :
String toto = null;
ça revient EXACTEMENT* à
String toto;
dans la mesure où si tu fais ça :
String toto = null;
if (test)
{
toto = "youpi";
}
if (toto.Length > 0)
{
...
}
Evec ton null t'as lair d'un con, tu plantes. donc tu dois modifier tous tes tests ensuite, afin de vérifier que la chaîne n'est pas égale à null.
*: "exactement" du point de vue de l'algo que je donne en exemple. il y a une grande différence entre une variable initialisée à null et une variable non initialisée du tout. sauf que ça plantera quand même quand on va vouloir l'appeler