Zeph (./427) :
pourquoi le constructeur statique vide ?

C'est un peu tordu à expliquer, mais en gros ça change la façon dont le constructeur statique est appelé. (Un attribut CIL sur la classe .NET générée)
Comme tu t'en doutes, l'initialisation des membres statiques se fait en réalité dans le constructeur statique, de même que l'initialisation des membres d'instance se fait dans le constructeur d'instance.
La version par défaut de l'initialisation statique en C# (pas de constructeur statique) laisse une grande latitude au JIT pour l'initialisation des membres statiques. En gros, le constructeur peut-être appelé n'importe quand, que ce soit au début de ton programme, au chargement de la classe, avant l'appel d'une méthode de la classe, à l'intérieur d'une méthode de la classe, ou même jamais. Malgré tout, tu conserves la garantie que le champ sera toujours initialisé au moment où tu en auras besoin (tu ne sais juste pas quand il sera initialisé).
La version avec constructeur statique est plus logique d'un point de vue humain, et se contente d'appeler le constructeur statique la première fois que tu utilises un membre de la classe. (Techniquement, il y a des chances que le « if (classInitialized) » se retrouve au milieu d'une ou plusieurs méthodes de ton code, selon l'état de ton programme. Même si ça n'est qu'un détail d'implémentation, ça peut avoir son importance, si ce test ce retrouve calé au milieu d'une boucle serrée…)

Personnellement, je suis plutôt partisan de la version sans constructeur statique, mais ça veut dire que le singleton (ainsi que tous les autres membres statiques s'il y en a) va potentiellement être instancié très tôt (ou très tard, dans le meilleur des cas). Ce n'est pas vraiment désirable dans le cas d'un objet lourd en mémoire ou en temps d'initialisation.

(Je sais pas si c'est clair… Et on peut ptet déplacer ça dans un autre topic aussi )

Pour documentation, voici la référence.

Folco (./428) :

GoldenCrystal (./426) :
Ça devrait économiser quelques octets de mémoire, et peut-être quelques cycles à chaque accès. (J'en suis presque certain, j'ai juste la flemme de faire les tests )

Bon écoute Golden, si vraiment tu veux progresser en programmation, arrête de compter les cycles et les octets pour les langages de haut niveau, tu m'as compris ?

Kevin > Ne vaut-il pas mieux déplacer le code d'initialisation du singleton (le else dans ton code) dans une méthode séparée afin que la méthode getInstance() soit inlinée proprement ailleurs dans le code ?