Et si ça se fait à l'exécution, je ne vois que 2 possibilités : -> soit c'est le JIT qui s'en charge -> soit c'est le code compilé La deuxième solution étant catastrophique au niveau performances, je suppose que ce n'est pas elle, mais il faudrait décompiler un programme pour s'en assurer.
-- Zazar
Bonsoir,
C'était aussi une déduction de mes petits neurones.Ca se fait à l'exécution
:
Et si ça se fait à l'exécution, je ne vois que 2 possibilités :
-> soit c'est le JIT qui s'en charge
-> soit c'est le code compilé
La deuxième solution étant catastrophique au niveau performances, je suppose
que ce n'est pas elle, mais il faudrait décompiler un programme pour s'en
assurer.
Et si ça se fait à l'exécution, je ne vois que 2 possibilités : -> soit c'est le JIT qui s'en charge -> soit c'est le code compilé La deuxième solution étant catastrophique au niveau performances, je suppose que ce n'est pas elle, mais il faudrait décompiler un programme pour s'en assurer.
-- Zazar
Zazar
Bonsoir,
Il n'y a "pratiquement" aucune différence.
En cherchant la petite bête, on peut cependant trouver des cas où on n'obtient pas le même résultat en remplaçant "" par String.Empty. Par exemple:
Le premier imprime True car la concaténation des deux littéraux est faite
à
la compilation.
Le second imprime False car la concaténation est faite à l'exécution (mais je ne suis pas sûr que ça soit garanti car un compilateur plus malin pourrait la faire en utilisant le fait que String.Empty est readonly -- la spec C# autorise t'elle ça? Si elle l'autorise, alors on a le risque
d'avoir
du code qui donne des résultats différents avec des compilateurs différents).
A ma connaissance, la spec ne dit pas que "" + "" doit être remplacé à la compilation par "". On n'est donc déjà en présence d'un comportement indéfini dans le premier cas.
-- Zazar
Bonsoir,
Il n'y a "pratiquement" aucune différence.
En cherchant la petite bête, on peut cependant trouver des cas où on
n'obtient pas le même résultat en remplaçant "" par String.Empty. Par
exemple:
Le premier imprime True car la concaténation des deux littéraux est faite
à
la compilation.
Le second imprime False car la concaténation est faite à l'exécution (mais
je ne suis pas sûr que ça soit garanti car un compilateur plus malin
pourrait la faire en utilisant le fait que String.Empty est readonly -- la
spec C# autorise t'elle ça? Si elle l'autorise, alors on a le risque
d'avoir
du code qui donne des résultats différents avec des compilateurs
différents).
A ma connaissance, la spec ne dit pas que "" + "" doit être remplacé à la
compilation par "". On n'est donc déjà en présence d'un comportement
indéfini dans le premier cas.
Le premier imprime True car la concaténation des deux littéraux est faite
à
la compilation.
Le second imprime False car la concaténation est faite à l'exécution (mais je ne suis pas sûr que ça soit garanti car un compilateur plus malin pourrait la faire en utilisant le fait que String.Empty est readonly -- la spec C# autorise t'elle ça? Si elle l'autorise, alors on a le risque
d'avoir
du code qui donne des résultats différents avec des compilateurs différents).
A ma connaissance, la spec ne dit pas que "" + "" doit être remplacé à la compilation par "". On n'est donc déjà en présence d'un comportement indéfini dans le premier cas.
-- Zazar
Bruno Jouhier [MVP]
> A ma connaissance, la spec ne dit pas que "" + "" doit être remplacé à la compilation par "". On n'est donc déjà en présence d'un comportement indéfini dans le premier cas.
C'est vrai en Java (section 3.10.5 du Gosling/Joy/Steele). J'ai peut-être généralisé un peu vite à C#.
Bruno.
-- Zazar
> A ma connaissance, la spec ne dit pas que "" + "" doit être remplacé à la
compilation par "". On n'est donc déjà en présence d'un comportement
indéfini dans le premier cas.
C'est vrai en Java (section 3.10.5 du Gosling/Joy/Steele). J'ai peut-être
généralisé un peu vite à C#.
> A ma connaissance, la spec ne dit pas que "" + "" doit être remplacé à la compilation par "". On n'est donc déjà en présence d'un comportement indéfini dans le premier cas.
C'est vrai en Java (section 3.10.5 du Gosling/Joy/Steele). J'ai peut-être généralisé un peu vite à C#.