2014-06-09 12 views
18

Użyłem odpowiedzi na to pytanie, List selectors for Objective-C object i wyszczególniłem wszystkie selektory, na które odpowiada mój obiekt klasy. Na wielkiej liście znalazłem selektor o nazwie ".cxx_destruct" (tak, zaczyna się kropka), widzę to po raz pierwszy i nigdy o tym nie słyszałem. Przeszukałem go i znalazłem to Objective C: ARC errors (Automatic release problems).iOS: ".cxx_destruct" - ukryty selektor w mojej klasie

Mam kilka pytań w głowie?

  • Czy jest to związane z ARC?
  • Jeśli jest selektorem, dlaczego jest ukryty?
  • Kiedy zadzwoni? Przez kogo sam system iOS?
  • Dlaczego nazywa się .cxx_destruct? jaka jest pełna forma "cxx" ..?
+0

Tak. Ponieważ jest związany z ARC i nie powinien być wywoływany ręcznie. Kiedy Twój obiekt zostanie zwolniony. Według obiektywnego środowiska wykonawczego C. Wzorzec nazw jest związany z destruktorami dla C++. – Petesh

+0

@Petesh, Czy możesz odwołać mnie do Apple Doc w tym celu? – Hemang

+0

Nie mam odniesienia do tego; To więcej niż poziom kompilatora, a nie tylko Apple. Kompilator automatycznie generuje '.cxx_destructor', gdy istnieją zmienne instancji typu obiektowego, aby zapewnić automatyczne dereferencje po zniszczeniu. To jest powód, dla którego nie trzeba pisać procedury dealloc, aby wyzerować wszystkie właściwości. Ma tytuł .cxx_destructor, ponieważ wykorzystuje zachowanie obiektu destruktor object ++. – Petesh

Odpowiedz

20

Przed ARC programiści musieliby celowo napisać rutynę dealloc, aby upewnić się, że wszystkie odniesienia do wszystkich obiektów, które zatrzymali, zostały zwolnione. To była praca ręczna i podatna na błędy.

Kiedy ARC został wprowadzony kod, który wykonuje równoważne zadanie, ponieważ te ręczne wydania musiałyby zostać zaimplementowane w każdym obiekcie, który nie posiadałby niczego więcej niż proste właściwości. Opieranie się na programistach ręcznie wdrażających rutynę dealloc może temu zaradzić.

Uwaga: To jest po prostu dla celów zarządzania count odniesienia podczas niszczenia obiektów. Jeśli chcesz usunąć obserwatorów lub wykonać inne prace porządkowe, nadal potrzebujesz procedury dealloc.

W rezultacie istniejące wcześniej mechanizm z objective-C++ użyto, czyli ukryty selektor nazywa .cxx_destruct który jest wywoływany automatycznie tuż przed obiektem są zwalniane. Ten selektor jest wywoływany automatycznie przez czas działania Objective C.

Dla kodu celu C++ istnieje równoległe .cxx_construct dla konstrukcji.

Ponownie, są one automatycznie generowane przez kompilator w celu radzenia sobie ze zniszczeniem obiektu w kontekście ARC. Możesz go zobaczyć, jeśli skompilujesz prosty, obiektywny kod C z właściwością obiektu i bez niego. Weź ten przykładowy kod:

#import <Foundation/Foundation.h> 

@interface Foo : NSObject 

@property (strong) NSObject *anobject; 

@end 

@implementation Foo 
@end 

int main() 
{ 
    Foo *f = [[Foo alloc] init]; 
    return 0; 
} 

Kiedy skompilować z łuku (clang -fobjc-arc test.m -o test -framework foundation) i zrzucić informacji o klasie widzimy selektor .cxx_destruct, kiedy skompilować bez ARC (clang -fnoobjc-arc test.m -o test -framework foundation), nie widzimy selektor .cxx_destruct. Jeśli skomentujesz właściwość NSObject *anobject i przekompilujesz, nie zobaczysz .cxx_destruct, ponieważ nie jest już potrzebna.

+0

Świetna odpowiedź! Jak uniknąć Xcode, aby uwzględnić go w raportach o pokryciu kodu? – SalvoC

+0

Nie wiem tego - nie oczekiwałbym, że pojawią się w typowych raportach dotyczących zasięgu, ponieważ nie są one mapowane do żadnych linii kodu źródłowego. – Petesh

+0

Ta odpowiedź wygląda na to, że próbuje również powiedzieć, że nie powinieneś implementować 'dealloc' w' ARC', ale to [nie jest prawdą] (http://stackoverflow.com/a/7292157/865175). –

Powiązane problemy