Entsprechend dem Abschnitt "10.12 Static constructors" von "C# Language Specification. Version 5.0" statischen Konstruktor kann mit "extern" Modifizierer markiert werden und in diesem Fall ist es ein externen statischen Konstruktor.Welchen Zweck haben externe statische Konstruktoren in C#?
Die gewöhnlichen (nicht-externen) statischen Konstruktoren sind wohlbekannt. Sie werden verwendet, um statische Felder und Eigenschaften zu initialisieren.
Die externen statischen Methoden werden oft verwendet, um native Funktionen über P/Invoke aufzurufen.
Und ich bin auch bewusst ziemlich esoterisch extern Konstruktoren (siehe auch this question). Zum Beispiel hat String Klasse mehrere solche declarations, diese Konstruktoren werden von der Laufzeit implementiert.
Aber sind die realen Verwendungen von externen statischen Konstrukteuren? Ich habe die coreclr repo durchsucht und nichts gefunden. Die Sprachspezifikation konnte keinem Konstrukt eine Beschreibung geben, das niemals in freier Wildbahn verwendet wurde. Oder könnte?
Meine Vermutung: C# hat externe statische Konstruktoren, nur weil CLR sie (im Prinzip) unterstützt.
Ich denke, Sie werden einen sehr ähnlichen Textabschnitt in jedem Unterabschnitt von Abschnitt 10 von 10.6 (Methoden) bis 10.13 (Destruktoren) finden. Wenn nichts anderes, ist es zumindest * konsistent *. –
Das einzige, was 'extern' tut, ist, den RVA der Methode auf 0 zu setzen. Die Laufzeit bleibt übrig, um den Rest herauszufinden. Siehe auch http://stackoverflow.com/q/38015024/. Es gibt wenig Grund für die Sprachspezifikation, dies zu verbieten, da die Arbeit des Compilers trivial ist (es wäre mehr Arbeit, sie zu verbieten). Da Konstruktoren nicht mit 'DllImport' gekennzeichnet werden können, besteht die einzige Möglichkeit, solche Methoden mit' MethodImplOptions.InternalCall' zu implementieren, so dass die Laufzeit der einzig mögliche Konsument ist, sodass es noch weniger interessant ist, dies explizit zu verbieten. –
Warum sie nicht wirklich verwendet werden, das gehört in den Bereich der Spekulation, aber wenn ich ein CLR-Implementierer wäre, würde ich lieber meine statische Initialisierung in einfach zu prognostizierenden Spots machen, anstatt mich auf die ziemlich geheimnisvollen Regeln zu verlassen zur Initialisierung von statischen Typen. All dieser Code ruft sowieso wieder in der Laufzeit auf, also würde es nichts anderes machen, als meine Arbeit zu erschweren. –