Ad ARC o non ad ARC? Quali sono i pro e i contro? [chiuso]

Devo ancora usare ARC, poiché la maggior parte del codice nel progetto a cui sto lavorando al momento è stata scritta prima di iOS 5.0.

Mi stavo solo chiedendo, la comodità di non conservare / rilasciare manualmente (e presumibilmente un codice più affidabile che ne deriva?) Supera il "costo" dell'utilizzo di ARC? Quali sono le tue esperienze con ARC e lo consiglieresti?

Così:

• Quali vantaggi può portare ARC a un progetto?
• ARC ha un costo come la garbage collection in Java?
• Hai usato ARC e, se sì, come l'hai trovato finora?

Non ci sono svantaggi. Usalo. Fallo oggi. È più veloce del tuo vecchio codice. È più sicuro del tuo vecchio codice. È più facile del tuo vecchio codice. Non è la raccolta dei rifiuti. Non ha overhead di runtime GC. Il compilatore inserisce conserva e rilascia in tutti i posti che dovresti avere comunque. Ma è più intelligente di te e può ottimizzare quelli che non sono effettivamente necessari (proprio come può srotolare loop, eliminare variabili temporanee, funzioni inline, ecc.)

OK, ora ti parlerò dei piccoli svantaggi:

• Se sei uno sviluppatore ObjC di lunga data, ti contrarrai per circa una settimana quando vedrai il codice ARC. Lo supererai molto rapidamente.

• Ci sono alcune (molto) piccole complicazioni nel collegamento al codice Core Foundation. Ci sono un po 'più complicazioni a che fare con tutto ciò che tratta un idcome void*. Cose come C-array di idpossono richiedere un po 'più di riflessione per essere eseguite correttamente. Anche la manipolazione stravagante di ObjC va_argspuò causare problemi. La maggior parte delle cose che coinvolgono la matematica su un puntatore ObjC è più complicata. Non dovresti avere molto di questo in ogni caso.

• Non si può mettere un idin un struct. Questo è abbastanza raro, ma a volte viene utilizzato per impacchettare i dati.

• Se non hai seguito la denominazione KVC corretta e mescoli codice ARC e non ARC, avrai problemi di memoria. ARC utilizza la denominazione KVC per prendere decisioni sulla gestione della memoria. Se è tutto codice ARC, non importa perché farà lo stesso "sbagliato" su entrambi i lati. Ma se è misto ARC / non-ARC, allora c'è una mancata corrispondenza.

• ARC perderà memoria durante i lanci di eccezioni ObjC. Un'eccezione ObjC dovrebbe essere molto vicina in tempo alla conclusione del programma. Se stai rilevando un numero significativo di eccezioni ObjC, le stai utilizzando in modo errato. Questo è risolvibile utilizzando -fobjc-arc-exceptions, ma incorre nelle sanzioni discusse di seguito:

• ARC non perderà memoria durante le eccezioni ObjC o C ++ nel codice ObjC ++, ma ciò è a scapito delle prestazioni di tempo e spazio. Questo è ancora un altro in un lungo elenco di motivi per ridurre al minimo l'utilizzo di ObjC ++.

• ARC non funzionerà affatto su iPhoneOS 3 o Mac OS X 10.5 o versioni precedenti. (Questo mi impedisce di utilizzare ARC in molti progetti.)

• __weaki puntatori non funzionano correttamente su iOS 4 o Mac OS X 10.6, il che è un peccato, ma abbastanza facile da aggirare. __weaki puntatori sono ottimi, ma non sono il punto vendita numero 1 di ARC.

Per il 95% + del codice disponibile, ARC è eccezionale e non c'è alcun motivo per evitarlo (a condizione che tu possa gestire le restrizioni della versione del sistema operativo). Per il codice non ARC, è possibile passare -fno-objc-arcfile per file. Xcode purtroppo rende questo molto più difficile di quanto dovrebbe essere in pratica. Probabilmente dovresti spostare il codice non ARC in un xcodeproj separato per semplificarlo.

In conclusione, passa ad ARC il prima possibile e non guardarti mai indietro.

MODIFICARE

Ho visto un paio di commenti sulla falsariga di "l'utilizzo di ARC non è un sostituto per conoscere le regole di gestione della memoria Cocoa". Questo è per lo più vero, ma è importante capire perché e perché no. Innanzitutto, se tutto il codice utilizza ARC e si violano le tre parole magicheovunque, non avrai ancora problemi. Scioccante da dire, ma eccoti. ARC potrebbe conservare alcune cose che non volevi conservare, ma rilascerà anche quelle, quindi non avrà mai importanza. Se oggi insegnassi una nuova classe a Cocoa, probabilmente non spenderei più di cinque minuti sulle effettive regole di gestione della memoria, e probabilmente menzionerei solo le regole di denominazione per la gestione della memoria mentre discuto dei nomi KVC. Con ARC, credo che potresti diventare un programmatore principiante decente senza imparare affatto le regole di gestione della memoria.

Ma non potresti diventare un programmatore intermedio decente. È necessario conoscere le regole per creare un collegamento corretto con Core Foundation e ogni programmatore intermedio deve affrontare la CF ad un certo punto. Ed è necessario conoscere le regole per il codice misto ARC / MRC. E devi conoscere le regole quando inizi a scherzare con i void*puntatori id(a cui continui a essere necessario per eseguire correttamente KVO). E i blocchi ... beh, la gestione della memoria a blocchi è semplicemente strana.

Quindi il mio punto è che la gestione della memoria sottostante è ancora importante, ma dove passavo molto tempo a stabilire e riaffermare le regole per i nuovi programmatori, con ARC sta diventando un argomento più avanzato. Preferisco che i nuovi sviluppatori pensino in termini di grafi a oggetti piuttosto che riempirsi la testa con le chiamate sottostanti a objc_retain().

Verranno risposte migliori e più tecniche delle mie, ma ecco qui:

• ARC! = Garbage Collection. Non è prevista alcuna penalità per il tempo di esecuzione, viene eseguita in fase di compilazione.
• Anche ARC! = Rilascia tutto automaticamente, come suggerisci nel tuo commento. Leggi i documenti
• E 'impressionante una volta che si rendono conto di quanto la gestione manuale di riferimento si stavano facendo
• Usalo!
• Uno svantaggio: mantenere il vecchio codice senza arco diventa improvvisamente molto noioso.

Quali vantaggi può portare ARC a un progetto?

Il vantaggio è un grado significativo di protezione dai comuni errori di gestione della memoria. Le perdite causate dal mancato rilascio di un oggetto e gli arresti anomali dovuti alla mancata conservazione o al rilascio prematuro di un oggetto dovrebbero essere notevolmente ridotti. È ancora necessario comprendere il modello di memoria conteggio dei riferimenti in modo da poter classificare i riferimenti come forti o deboli, evitare cicli di conservazione e così via.

Quanto "costa" realmente la raccolta dei rifiuti?

Non è presente la raccolta dei rifiuti in iOS. ARC è simile a GC in quanto non è necessario conservare o rilasciare manualmente gli oggetti. È diverso da GC in quanto non esiste un garbage collector. Il modello di conservazione / rilascio si applica ancora, è solo che il compilatore inserisce le chiamate di gestione della memoria appropriate nel codice per te in fase di compilazione.

Hai usato ARC e, se sì, come l'hai trovato finora?

È un po 'sconcertante se sei abituato a fare riferimento al conteggio, ma è solo questione di abituarti e imparare a credere che il compilatore farà davvero la cosa giusta. Sembra una continuazione del cambiamento alle proprietà fornito con Objective-C 2.0, che è stato un altro grande passo verso la semplificazione della gestione della memoria. Senza le chiamate di gestione della memoria manuale, il codice diventa un po 'più breve e più facile da leggere.

L'unico problema con ARC è che non è supportato nelle versioni precedenti di iOS, quindi è necessario tenerne conto prima di decidere di adottarlo.

Penso che ARC sia un'ottima idea. Rispetto a GC, puoi avere la tua torta e mangiarla anche tu. Tendo a credere che MRC imponga una "disciplina" inestimabile verso la gestione della memoria che tutti trarrebbero vantaggio dall'avere. Ma sono anche d'accordo sul fatto che il vero problema di cui essere consapevoli è la proprietà degli oggetti e i grafici degli oggetti (come molti hanno sottolineato) e non i conteggi di riferimento di basso livello di per sé.

Per concludere: ARC NON è un pass gratuito per non pensare alla memoria; è uno strumento per aiutare gli esseri umani a evitare compiti ripetitivi, che causano stress e sono soggetti a errori, quindi meglio delegati a una macchina (il compilatore, in questo caso).

Detto questo, personalmente sono una specie di artigiano e non ho ancora effettuato la transizione. Ho appena iniziato a usare Git ...

AGGIORNAMENTO: Quindi ho migrato tutto il mio gioco, libreria gl inclusa, e nessun problema fino ad ora (tranne con l'assistente di migrazione in Xcode 4.2). Se stai iniziando un nuovo progetto, fallo.

L'ho usato in un paio di progetti (certamente piccoli) e ho solo buone esperienze, sia in termini di prestazioni che di affidabilità.

Una piccola nota di cautela è che devi imparare le cose da fare e da non fare dei riferimenti deboli per non causare alcun loop di riferimento se stai codificando la tua interfaccia utente da solo, il progettista tende a fare un buon lavoro automaticamente se imposti la tua GUI usandola.

L'unico svantaggio che ho riscontrato è se utilizzi una libreria con molte funzioni e dati CoreFoundation. In MRC non era necessario preoccuparsi di utilizzare un CFStringRefinvece di un file NSString*. In ARC, devi specificare come i due interagiscono (bridge di base? Rilasciare l'oggetto CoreFoundation e spostarlo su ARC? Creare un oggetto Cocoa come oggetto trattenuto da CoreFoundation +1?) Inoltre, su OS X, è disponibile solo su 64- codice bit (anche se ho un'intestazione che funziona intorno a questo ...).