W jaki sposób można wyłączyć ostrzeżenie o statycznym analizatorze Xcode Clang?

Question

"Potencjalny wyciek obiektu przydzielonego w linii n i zapisany w zmiennej" zmienna "."

Zwykle jest to bardzo pomocne ostrzeżenie analizator, ale istnieje kilka sytuacji, w których mogę zrobić irytujące fałszywych alarmów, które chciałbym, aby stłumić, aby moje wyniki analizatora czyste. W obronie analizatora, to, co dostrzega, z pewnością byłoby wyciekiem pamięci, gdyby nie uwolnienie na innej ścieżce wykonania (do której jest ślepa).

Zajmę się moją sytuacją. Zdarza się to w różnych smakach, ale ogólny wzór jest następujący:

1. Obiekt zostaje przydzielony, a jego uczestnik jest ustawiony.
2. Coś jest zrobione z obiektem. (Zadanie rozpoczęte, wyświetlany widok, itp.).
3. Zakończono wykonywanie bieżącej metody. (Wprowadź ostrzeżenie o Clang).
4. Obiekt decyduje, że jego zadanie zostało zakończone, wysyła delegata wiadomość.
5. Delegat zwalnia obiekt.

To wcale nie jest ezoteryczny wzór, więc mam nadzieję, że tłumienie jest możliwe. Wiem, że można tego uniknąć, przechowując obrażliwy obiekt w ivar, który jest później zwolniony, ale bardzo wolę nie dodawać zanieczyszczenia ivar.

Answer 1

Clang ma kilka nowych Source Annotations. W szczególności możesz być zainteresowany atrybutem ns_consumed.

Answer 2

Myślę, że powinieneś posłuchać w tym przypadku komunikatu statycznego analizatora. Twój wzór ma potencjalne problemy.

W szczególności, po powrocie z metody wywołanej do wykonania kroku 5, znajdujesz się w metodzie obiektu, który mógł już zostać zwolniony. I interpretować coś wzór takiego:

// steps 1, 2, 3 
-(void) methodThatCreatesObject 
{ 
    id theObj = [[TheObj alloc] init]; 
    [theObj setDelegate: delegateObj]; 
    // other stuff 
} 

Uwaga Powyższe narusza memory management rules

// step 4 - a method of theObj 
-(void) someMethod 
{ 
    [delegate notifyTaskCompleteFromObj: self]; 
    // self points to an invalid object here. Doing anything with self results in EXC_BAD_ACCESS 
} 

Powyższe naruszy założenie określone w zasadach zarządzania pamięcią:

Odebrany obiekt jest normalnie gwarantowana ważność w ramach metody, w której została otrzymana:

jeśli powiemy, że self jest odebranym obiektem, który jest technicznie, ponieważ jest przekazywany jako parametr na stosie.

// step 5 the delegate method defined in the delegate object 

-(void) notifyTaskCompleteFromObj: (TheObj*) anObj 
{ 
    // do stuff 
    [anObj release]; 
} 

Powyższe łamie również zasady zarządzania pamięcią.

Normalny wzór to posiadanie kontrolera, który jest właścicielem zarówno delegata, jak i obiektu, który ma delegata (często kontroler sam jest delegatem). Myślę, że powinieneś przejść do tego schematu.

Answer 3

Przyszła mi kolejna interesująca opcja. OP podał następujący scenariusz:

1. Obiekt zostaje przydzielony, a jego uczestnik jest ustawiony.
2. Coś jest zrobione z obiektem. (Zadanie rozpoczęte, wyświetlany widok, itp.).
3. Zakończono wykonywanie bieżącej metody. (Wprowadź ostrzeżenie o Clang).
4. Obiekt decyduje, że jego zadanie zostało zakończone, wysyła delegata wiadomość.
5. Delegat zwalnia obiekt.

Jeżeli zamiast wyraźnego zwolnienia, to po prostu chciał przedłużyć żywotność przydzielonego obiektu do obiektu Alokacja/delegeate, można do tego:

TheObject* foo = [[TheObject alloc] init] autorelease]; 
foo.delegate = self; 
[foo doSomething]; 
objc_setAssociatedObject(self, foo, foo, OBJC_ASSOCIATION_RETAIN_NONATOMIC); 
return; 

Ustawiając foo jako powiązany obiekt z polityką zachowania, osoba delegowana (self) skutecznie zachowuje obiekt, który zostanie następnie zwolniony za każdym razem, gdy delegat (self) zostanie zwolniony (później).

To nie jest DOKŁADNIE to, o co poprosił PO, ale jest to jednak przydatny wzór i wydaje się, że prawdopodobnie wystarczyłoby w sytuacji, którą przedstawił PO.