Dlaczego muszę wywoływać super-wstępne alokacje na końcu, a nie pierwsze?

Question

poprawny przykład:

- (void)dealloc { 
    [viewController release]; 
    [window release]; 
    [super dealloc]; 
} 

źle przykład:

- (void)dealloc { 
    [super dealloc]; 
    [viewController release]; 
    [window release]; 
} 

Althoug w alsmost wszystkich innych przypadkach, gdy przesłanianie metody Chciałbym najpierw zadzwonić do wdrożenia metody super jest, w tym przypadku jabłka zawsze wywołuje [SUPER dealloc ] na końcu. Czemu?

Answer 1

To tylko wytyczna. Możesz zadzwonić po inne instrukcje po [super dealloc]. jednak nie można już uzyskać dostępu do zmiennych nadklasy, ponieważ są one zwalniane po wywołaniu [super dealloc]. Zawsze można bezpiecznie wywołać superklasę w ostatniej linii.

Również klucze KVO i zależne (wyzwalane) mogą wywoływać efekty uboczne, jeśli są zależne od już zwolnionych zmiennych składowych.

Answer 2

Nie wiem nic o programowaniu dla iPhone'a, ale zakładam, że to z tego samego powodu, że destruktory muszą być wywoływane w odwrotnej kolejności. Chcesz się upewnić, że wszystkie twoje "śmieci" zostaną oczyszczone przed wywołaniem twojej nadklasy. Jeśli zrobisz to na odwrót, rzeczy mogą stać się bałaganiarskie. Na przykład, jeśli destruktor musi uzyskać dostęp do pamięci, że super destructor został już uwolniony:

class X { 
    private Map foo; 

    function __construct() { 
     foo = new Map(); 
    } 

    function __destruct() { 
     foo.free; 
    } 
} 

class Y extends X { 
    function __construct() { 
     super.__construct(); 
     map.put("foo", 42); 
    } 

    function __destruct() { 
     super.__destruct(); 
     if (map.containsKey("foo")) { // boooooooooom! 
      doSomething(); 
     } 
    } 
} 

Nie możesz napotkać ten problem w kodzie, ponieważ „wiesz co robisz”, ale jest bezpieczniejszą i ogólnie lepszą praktyką, aby nie robić takich rzeczy.

Answer 3

[super dealloc] zwalnia pamięć używaną przez obiekt, w tym wskaźniki do viewController i okna. Odwoływanie się do zmiennych po ich uwolnieniu jest w najlepszym wypadku niebezpieczne.

Zobacz this answer.

Answer 4

Praktycznie prawie na końcu masz [super dealloc], ponieważ uwalnia on zmienne nadklasy i nie można już uzyskać do nich dostępu.

Jeden wyjątek dotyczy podklasy UITableViewController, która używa innej klasy jako delegata widoku tabeli. W takim przypadku musisz zwolnić delegata widoku tabeli po [super dealloc], ponieważ widok tabeli odwołuje się do delegata widoku tabeli, a widok tabeli musi zostać najpierw zwolniony.

Answer 5

Oto prawdziwy przykład, gdzie [super dealok] musi być ostatni, w przeciwnym razie wywołanie removeFromRunLoop spowoduje awarię. Nie jestem pewien, co dzieje się wewnątrz removeFromRoLoop NSOutputStream, ale wydaje się, że w tym przypadku uzyskuje dostęp do "self".

Setup:

[outputStream setDelegate:self]; 
[outputStream scheduleInRunLoop:[NSRunLoop currentRunLoop] forMode:NSDefaultRunLoopMode]; 

dealloc:

- (void)dealloc { 
    if (outputStream) { 
     [outputStream close]; 
     [outputStream removeFromRunLoop:[NSRunLoop currentRunLoop] 
           forMode:NSDefaultRunLoopMode]; 
     [outputStream release]; 
     outputStream = nil; 
    } 
    delegate = nil; 
    [super dealloc]; // must be last! 
} 

Answer 6

[do ostatniego postu] Czy nie tableview odwołującego delegata jest odpowiedzialny za emisję własną delegat? Wydaje mi się, że zachował ją, gdy był ustawiony (abyś mógł go zwolnić lub samozwaszyć) i sam się o to zatroszczył?

Jeśli chodzi o pytanie OP, zawsze będę dzwonił super pierwszy, jeśli będę konstruował i dzwoni super super, jeśli ulegam destrukcji.Myślę o tym, że "chcę super zbudować to, co chce, więc mogę na tym oprzeć i chcę, żeby super zburzyło się po tym, jak posprzątam po sobie". Praktycznie wszystkie wywołania, z których korzystam, są konstruowane, z wyjątkiem dealloc, dlatego zawsze będziesz je widział w moim kodzie dealloc.