Odpowiedzi Yuvala i Davida są w zasadzie poprawne; Podsumowując:
- Użycie nieprzypisanej zmiennej lokalnej jest prawdopodobnym błędem, który kompilator może wykryć niewielkim kosztem.
- Użycie nieprzypisanego pola lub elementu tablicy jest mniej prawdopodobnym błędem i trudniej jest wykryć warunek w kompilatorze. Dlatego kompilator nie próbuje wykryć użycia niezainicjowanej zmiennej dla pól i zamiast tego opiera się na inicjalizacji do wartości domyślnej, aby określić zachowanie programu.
Komentator odpowiedzi Davida pyta, dlaczego niemożliwe jest wykrycie użycia nieprzypisanego pola za pomocą analizy statycznej; jest to punkt, który chcę rozwinąć w tej odpowiedzi.
Po pierwsze, dla jakiejkolwiek zmiennej, lokalnej lub innej, w praktyce niemożliwe jest dokładne określenie , czy zmienna jest przypisana, czy nieprzypisana. Rozważać:
bool x;
if (M()) x = true;
Console.WriteLine(x);
Pytanie „czy x jest przypisane?” jest równoważne z „czy M () zwraca prawdę?” Teraz załóżmy, że M () zwraca prawdę, jeśli Ostatnie twierdzenie Fermata jest prawdziwe dla wszystkich liczb całkowitych mniejszych niż jedenaście gajillionów, a fałsz w przeciwnym razie. Aby ustalić, czy x jest definitywnie przypisane, kompilator musi zasadniczo przedstawić dowód ostatniego twierdzenia Fermata. Kompilator nie jest taki inteligentny.
Więc kompilator zamiast tego dla lokalnych implementuje algorytm, który jest szybki i przeszacowuje, gdy lokalna nie jest ostatecznie przypisana. Oznacza to, że ma kilka fałszywych alarmów, gdzie mówi „Nie mogę udowodnić, że ten lokalny jest przypisany”, mimo że ty i ja wiemy, że tak. Na przykład:
bool x;
if (N() * 0 == 0) x = true;
Console.WriteLine(x);
Załóżmy, że N () zwraca liczbę całkowitą. Ty i ja wiemy, że N () * 0 będzie równe 0, ale kompilator tego nie wie. (Uwaga: C # 2.0 kompilator nie wiem, ale usunąłem że optymalizacja, a specyfikacja nie powiedzieć , że kompilator wie, że).
W porządku, więc co wiemy do tej pory? Uzyskanie dokładnej odpowiedzi przez mieszkańców jest niepraktyczne, ale możemy tanio przecenić nieprzypisane wartości i uzyskać całkiem niezły wynik, który zawiera błędy po stronie „spraw, abyś naprawił swój niejasny program”. Dobre. Dlaczego nie zrobić tego samego dla pól? To znaczy stworzyć określony moduł sprawdzania zadań, który przecenia tanio?
Cóż, na ile jest sposobów inicjalizacji lokalnego? Można to przypisać w tekście metody. Można go przypisać wewnątrz lambda w tekście metody; że lambda może nigdy nie zostać wywołana, więc te przypisania nie są istotne. Lub można go przekazać jako „out” do innej metody, w którym to momencie możemy założyć, że jest przypisany, gdy metoda zwraca normalnie. Są to bardzo wyraźne punkty, w których przypisywany jest lokalny, i znajdują się tam w ten sam sposób, w jaki deklarowany jest lokalny . Określenie konkretnego przypisania dla lokalnych wymaga jedynie analizy lokalnej . Metody są zwykle krótkie - o wiele mniej niż milion wierszy kodu w metodzie - więc analiza całej metody jest dość szybka.
A co z polami? Pola można oczywiście zainicjować w konstruktorze. Lub inicjator pola. Lub konstruktor może wywołać metodę instancji, która inicjuje pola. Lub konstruktor może wywołać metodę wirtualną , która inicjalizuje pola. Lub konstruktor może wywołać metodę z innej klasy , która może znajdować się w bibliotece , która inicjuje pola. Pola statyczne można inicjować w konstruktorach statycznych. Pola statyczne mogą być inicjowane przez inne konstruktory statyczne.
Zasadniczo inicjator dla pola może znajdować się w dowolnym miejscu w całym programie , w tym wewnątrz metod wirtualnych, które zostaną zadeklarowane w bibliotekach, które nie zostały jeszcze napisane :
// Library written by BarCorp
public abstract class Bar
{
// Derived class is responsible for initializing x.
protected int x;
protected abstract void InitializeX();
public void M()
{
InitializeX();
Console.WriteLine(x);
}
}
Czy kompilowanie tej biblioteki jest błędem? Jeśli tak, w jaki sposób BarCorp ma naprawić błąd? Przypisując wartość domyślną do x? Ale to już robi kompilator.
Załóżmy, że ta biblioteka jest legalna. Jeśli FooCorp pisze
public class Foo : Bar
{
protected override void InitializeX() { }
}
Jest to błąd? Jak kompilator ma to rozgryźć? Jedynym sposobem jest wykonanie całej analizy programu, która śledzi statyczne inicjowanie każdego pola na każdej możliwej ścieżce w programie , w tym ścieżki, które obejmują wybór metod wirtualnych w czasie wykonywania . Ten problem może być arbitralnie trudny ; może obejmować symulowane wykonanie milionów ścieżek sterowania. Analiza lokalnych przepływów sterowania zajmuje mikrosekundy i zależy od rozmiaru metody. Analiza globalnych przepływów kontrolnych może zająć wiele godzin, ponieważ zależy to od złożoności każdej metody w programie i wszystkich bibliotek .
Dlaczego więc nie przeprowadzić tańszej analizy, która nie musi analizować całego programu, a po prostu jeszcze bardziej zawyżać? Cóż, zaproponuj algorytm, który działa i nie utrudnia napisania poprawnego programu, który faktycznie się kompiluje, a zespół projektowy może to rozważyć. Nie znam żadnego takiego algorytmu.
Teraz komentator sugeruje „wymagaj, aby konstruktor zainicjował wszystkie pola”. To nie jest zły pomysł. W rzeczywistości jest to niezły pomysł, że C # ma już tę funkcję dla struktur . Konstruktor struktury jest wymagany do ostatecznego przypisania wszystkich pól do czasu normalnego powrotu ctora; domyślny konstruktor inicjuje wszystkie pola do ich wartości domyślnych.
A co z zajęciami? Cóż, jak wiesz, że konstruktor został zainicjowany pole ? Ctor mógłby wywołać metodę wirtualną w celu zainicjowania pól, a teraz jesteśmy z powrotem w tej samej pozycji, w której byliśmy wcześniej. Struktury nie mają klas pochodnych; klasy mogą. Czy biblioteka zawierająca klasę abstrakcyjną musi zawierać konstruktora, który inicjuje wszystkie jej pola? Skąd klasa abstrakcyjna wie, jakie wartości powinny mieć pola?
John sugeruje po prostu zakaz wywoływania metod w ctor przed zainicjalizowaniem pól. Podsumowując, nasze opcje to:
- Uczyń powszechne, bezpieczne, często używane idiomy programistyczne jako nielegalne.
- Wykonaj kosztowną analizę całego programu, która spowoduje, że kompilacja zajmie wiele godzin w celu wyszukania błędów, których prawdopodobnie nie ma.
- Polegaj na automatycznej inicjalizacji do wartości domyślnych.
Zespół projektowy wybrał trzecią opcję.