Zrozumienie C Wymagania inicjalizacji # pole

Question

Biorąc pod uwagę następujący kod:

public class Progressor 
{ 
    private IProgress<int> progress = new Progress<int>(OnProgress); 

    private void OnProgress(int value) 
    { 
     //whatever 
    } 
} 

To daje następujący błąd na kompilacji:

A field initializer cannot reference the non-static field, method, or property 'Progressor.OnProgress(int)'

Rozumiem, ograniczenie to nie narzeka, ale ja nie rozumiem dlaczego jest to problem, ale pole można zainicjować w konstruktorze w następujący sposób:

public class Progressor 
{ 
    private IProgress<int> progress; 

    public Progressor() 
    { 
     progress = new Progress<int>(OnProgress); 
    } 

    private void OnProgress(int value) 
    { 
     //whatever 
    } 
} 

Jaka jest różnica w C# w odniesieniu do inicjalizacji pola w porównaniu do inicjacji konstruktora, która wymaga tego ograniczenia?

Answer 1

Inicjalizacja pól przychodzi przed wywołaniem konstruktora klasy podstawowej, więc nie jest poprawnym obiektem. Każde wywołanie metody z this jako argumentem w tym miejscu prowadzi do niezweryfikowanego kodu i wyrzucenia VerificationException, jeśli nie można zweryfikować kodu. Na przykład: w przezroczystym kodzie zabezpieczeń.

• 10.11.2 Instance variable initializers
  When an instance constructor has no constructor initializer, or it has a constructor initializer of the form base(...), that constructor implicitly performs the initializations specified by the variable-initializers of the instance fields declared in its class. This corresponds to a sequence of assignments that are executed immediately upon entry to the constructor and before the implicit invocation of the direct base class constructor. The variable initializers are executed in the textual order in which they appear in the class declaration.
• 10.11.3 Constructor execution
  Variable initializers are transformed into assignment statements, and these assignment statements are executed before the invocation of the base class instance constructor. This ordering ensures that all instance fields are initialized by their variable initializers before any statements that have access to that instance are executed.

Answer 2

Sekcja 10.5.5.2: Instance inicjalizacji pola opisuje ten problem:

A variable initializer for an instance field cannot reference the instance being created. Thus, it is a compile-time error to reference this in a variable initializer, as it is a compile-time error for a variable initializer to reference any instance member through a simple-name

Takie zachowanie ma zastosowanie do kodu ponieważ OnProgress jest niejawna odwołanie do instancji tworzone.

Answer 3

Odpowiedź brzmi mniej więcej, projektanci C# preferowali to w ten sposób.

Ponieważ wszystkie inicjatory polowe są tłumaczone na instrukcje w konstruktorze, które występują przed innymi instrukcjami w konstruktorze, nie ma technicznych przyczyn, dla których nie byłoby to możliwe. Jest to więc wybór projektu.

Dobrą cechą konstruktora jest to, że wyjaśnia, w jakiej kolejności wykonywane są zadania.

Należy zauważyć, że z członkami static, projektanci C# postanowili inaczej. Np

static int a = 10; 
static int b = a; 

jest dozwolone, i różni się od tego (również możliwość)

static int b = a; 
static int a = 10; 

co może być mylące.

Jeśli się:

partial class C 
{ 
    static int b = a; 
} 

i gdzie indziej (w innym pliku):

partial class C 
{ 
    static int a = 10; 
} 

ja nawet nie myślę, że jest dobrze zdefiniowany, co się wydarzy.

oczywiście dla konkretnego przykładu z delegatów do inicjowania instancji pola:

Action<int> progress = OnProgress; // ILLEGAL (non-static method OnProgress) 

naprawdę nie ma problemu, ponieważ to nie jest tylko do odczytu lub wywołanie członu non-statycznego. Zamiast tego używa się informacji o metodach i nie zależy to od jakiejkolwiek inicjalizacji. Ale zgodnie ze specyfikacją języka C# nadal jest to błąd podczas kompilacji.

Answer 4

Wszystko w mojej odpowiedzi to tylko moje przemyślenia na temat "dlaczego niebezpiecznie byłoby zezwolić na ten rodzaj dostępu". Nie wiem, czy to był prawdziwy powód, dla którego był ograniczony.

C# specyfikacja mówi, że inicjalizacji pola dzieje się w dziedzinie zamówień są zadeklarowane w klasie:

10.5.5.2. Instance field initialization

The variable initializers are executed in the textual order in which they appear in the class declaration.

Teraz, powiedzmy, że kod już wspomniano jest to możliwe - można wywołać metodę instancji z pola inicjalizacja. Może to zrobić następujący kod:

public class Progressor 
{ 
    private string _first = "something"; 
    private string _second = GetMyString(); 

    private string GetMyString() 
    { 
     return "this is really important string"; 
    } 
} 

Jak dotąd tak dobrze. Ale bądźmy nadużywają tej władzy trochę:

public class Progressor 
{ 
    private string _first = "something"; 
    private string _second = GetMyString(); 
    private string _third = "hey!"; 

    private string GetMyString() 
    { 
     _third = "not hey!"; 
     return "this is really important string"; 
    } 
} 

Więc _second get zainicjowany przed _third. GetMyString działa, _third get "nie hej!" przypisana wartość, ale później uruchamia się własna inicjalizacja pola i jest ustawiana na "" hej! ". Niezbyt przydatne, czytelne, prawda?

Można również użyć _third ciągu GetMyString metody:

public class Progressor 
{ 
    private string _first = "something"; 
    private string _second = GetMyString(); 
    private string _third = "hey!"; 

    private string GetMyString() 
    { 
     return _third.Substring(0, 1); 
    } 
} 

Co można oczekiwać, aby być wartość _second? Cóż, przed uruchomieniem inicjalizacji pola wszystkie pola otrzymują wartości domyślne. Dla string będzie to null, więc otrzymasz niespodziewany NullReferenceException.

Tak więc projektanci zdecydowali, że łatwiej jest zapobiec takim błędom.

Można powiedzieć: OK, niech zabraknie dostępu do właściwości i metod wywoływania, ale pozwólmy na użycie pól, które zostały zadeklarowane powyżej tego, z którego chcesz uzyskać do niego dostęp. Coś jak:

public class Progressor 
{ 
    private string _first = "something"; 
    private string _second = _first.ToUpperInvariant(); 
} 

ale nie

public class Progressor 
{ 
    private string _first = "something"; 
    private string _second = _third.ToUpperInvariant(); 
    private string _third = "another"; 
} 

To wydaje się użyteczne i bezpieczne. Ale wciąż jest sposób na jej nadużycie!

public class Progressor 
{ 
    private Lazy<string> _first = new Lazy<string>(GetMyString); 
    private string _second = _first.Value; 

    private string GetMyString() 
    { 
     // pick one from above examples 
    } 
} 

I wszystkie problemy z metodami powracają.