Warum brauchen wir statische Konstruktoren?

Wenn Sie diese Klasse in eine Assembly kompilieren und dann ILSpy o.ä. verwenden, um das Ergebnis zu disassemblieren, werden Sie feststellen, dass die Initialisierung aller statischen Elemente im statischen Konstruktor ausgeführt wird.

Zum Beispiel der folgende C # -Code:

Produziert IL entsprechend:

Mit anderen Worten, direkte Initialisierung ist nur syntaktischer Zucker, der vom C # -Compiler bereitgestellt wird. Unter der Haube ist noch ein statischer Konstruktor implementiert.

Nun, in Ihrem Beispiel wird es zwar nicht benötigt, aber stellen Sie sich vor, wenn i value aus einer Datenbank, Textdatei oder einer anderen Ressource gelesen werden muss? Möglicherweise benötigen Sie etwas wie:

Jetzt ist es nicht möglich, Ihr statisches Feld zu deklarieren und zu initialisieren, Sie werden besser mit einem statischen Konstruktor bedient

Sie benötigen in diesem Szenario keinen statischen Konstruktor.

und

sind funktional identisch.

Die Antwort ist auch in Ihrer verknüpften Frage:

  

[...] insbesondere nützlich zum Lesen erforderlicher Konfigurationsdaten in schreibgeschützte Felder usw.

     

Es wird beim ersten Mal automatisch von der Laufzeitumgebung ausgeführt (die genauen Regeln dort & gt; sind kompliziert (siehe "beforefieldinit") und werden subtil zwischen CLR2 und CLR4 geändert). & gt; Wenn Sie die Reflektion nicht missbrauchen, läuft sie garantiert höchstens einmal (auch wenn zwei Threads gleichzeitig ankommen).

Sie könnten viel kompliziertere Dinge in einem statischen Konstruktor initialisieren, wie das Einrichten einer Datenbankverbindung und so weiter. Wenn es Sinn machen würde, ist eine andere Sache ...

Ein statischer Contructor ist sinnvoll, wenn Sie einige Aktionen innerhalb des Konstruktors ausführen müssen und Sie eine eindeutige Instanz in der Anwendung wünschen. Zum Beispiel:

In dem von Ihnen erläuterten Szenario benötigen Sie keinen statischen Konstruktor explizit.

Sie können auch das Singleton-Muster anwenden, um diesen Zweck zu erreichen.

Ein statischer Konstruktor dient nicht nur zum Initialisieren von Variablen, sondern auch zum Erstellen von Objekten, die für Ihre (statische) Klasse (oder Umgebung) notwendig sind, um Methoden für diese Objekte oder Ihre Klasse selbst zu verwenden und aufzurufen.

Sie können Felder an Ort und Stelle nur mit Kompilierzeitkonstanten (Ihrem Fall) initialisieren. Aber im statischen Konstruktor können Sie etwas Code ausführen (z. B. Konfigurationsdatei lesen).

Ein noch nicht erwähnter Faktor ist, dass es einen semantischen Unterschied zwischen einem statischen Konstruktor (geschrieben mit Konstruktorsyntax) und dem Aufruf von foo() gegenüber einem statischen Feldinitialisierer gibt. Insbesondere wenn ein Typ einen statischen Konstruktor hat, der mit der Konstruktorsyntax geschrieben wurde, wird garantiert, dass dieser Konstruktor den ersten Zeitcode aufgerufen wird, der diesen Typ "verwenden" würde; Es wird vorher nicht aufgerufen und auch nicht aufgerufen, wenn der Typ nicht verwendet wird. Im Gegensatz dazu garantiert .NET zwar, dass die statischen Feldinitialisierer eines Typs vor dem Zugriff auf seine statischen Felder ausgeführt werden und nicht mehr als einmal ausgeführt werden. .NET kann jedoch solche statischen Initialisierer beim ersten Auftreten eines Typs könnte verwendet werden. Betrachten Sie zum Beispiel:

Wenn der Just-In-Time-Compiler den obigen Code findet, someClass noch nie verwendet wurde und ein Konstruktor mit der statischen Konstruktorsyntax deklariert wurde, lautet der resultierende Maschinencode etwa:

Ausführen des if-check innerhalb der Schleife. Wenn dagegen Feldinitialisierungen, aber keine Deklaration im Konstruktorstil stattgefunden hätten, würde der JIT wahrscheinlich die statische Konstruktion von someClass ausführen, bevor er den Code ausführt, wodurch die if -Kontrolle nicht mehr darin enthalten sein muss.