Was ist der richtige Weg, um zu erklären, eine readonly-Eigenschaft für ios mit ARC

Ich bin neu in der iOS-Entwicklung im Allgemeinen und haben nie befasst mit manuellem reference counting (retain, release, autorelease). Als solche, die ich nicht haben ein gutes Verständnis von dem, was Magie ARC durchführt.

Ich dachte, ich Verstand, bis ich gefragt wurde, welche Art von Eigentum ( weak , strong, assign etc) sollte gegeben werden, um eine readonly-Eigenschaft auf ein Objekt gerichtet, wie:

@property (readonly,nonatomic) NSString* name;

Ich hier gelesen habe
Fragen über eine readonly - @Immobilien in BOGEN das verlassen der strong/weak nicht wirklich kompilieren, es sei denn, Sie geben einen Rückhalt variable, wenn Sie @synthesize Eigentum, ich habe Sie nur so geschehen zu sein, die Angabe background-ivar wie diese:

@synthesize name = _name;

Jetzt verstehe ich, dass der Standard-Lebenszeit des qualifier' einer Variablen ist stark, von hier: http://developer.apple.com/library/ios/releasenotes/ObjectiveC/RN-TransitioningToARC/Introduction/Introduction.html#//apple_ref/doc/uid/TP40011226-CH1-SW4

So, um zu schneiden eine lange Geschichte kurz - ich bin indirekt die Definition meiner Eigenschaft als (readonly,nonatomic,strong) als _name ivar ist implizit deklariert als __strong.

Habe ich ein paar Fragen:

  1. Ist strong richtigen Leben qualifier verwenden? Ich gehe davon aus, dass es ist, sonst wird das Objekt sichern meine NSString* wäre nicht im Besitz überall und würde somit automatisch freigegeben (aus dem Java-land-dies macht Sinn, da alle Referenzen sind starke Standard).

  2. Gibt es noch andere Modifikatoren, die Sinn machen in dieser situation, wie copy oder assign?

  3. Tut der Deklaration der Eigenschaft als (readonly,nonatomic,strong) und (readonly,nonatomic) keinen Unterschied machen, mit dem code, der verbraucht Eigentum? zB. nicht zu deklarieren, ohne die strong keyword Ursache der Objekt-Zeiger gespeichert werden, wie __unsafe_unretained wo die strong - Eigenschaft gespeichert werden, in einer __strong Zeiger?

Dank!

BEARBEITEN

So wie ich das jetzt verstehe, gilt das folgende für readonly-Eigenschaften:

  • Für nicht-NSObject* Typen (int, float, void*, etc) verwenden (readonly, assign).
  • Für Objekt-Pointer, verwenden Sie (readonly, strong) oder (readonly, copy) - diese Funktion das gleiche für readonly-Eigenschaften, aber Sie können die copy-Semantik bei Verlängerung/Unterklasse und deklarieren Sie die Eigenschaft wie readwrite.
  • Für den Objekt-Zeiger, (readonly, weak) macht nur Sinn, wenn Sie gehen, um die Speicherung einer bereits schwachen Zeiger in dieser Eigenschaft (die Zeiger müssen stark sein, an anderer Stelle oder das Objekt wird freigegeben).
  • Beachten Sie, dass zu "starke" impliziert ist, so dass, wenn Sie erweitern eine readonly angegeben (readonly) mit (strong) es wird funktionieren, aber (copy) nicht. Stattdessen würden Sie sehen, "ARC verbietet Synthese eine Eigenschaft ... mit unbekannter Eigentums-oder Speicher-Attribut." In diesem Fall müssen Sie explizit die header-definition (readwrite, copy). Dieser stolperte, mich für ein paar Minuten.
InformationsquelleAutor Wayne Uroda | 2012-05-22
  1. 12

    1. strong richtig ist zu verwenden, wenn Sie möchten, um eine starke (Besitz) Bezug zu was auch immer es ist, dass Sie zeigen. In der Regel, Sie wollen starke, aber um zu verhindern, dass zirkuläre Referenzen (insbesondere in Eltern - /Kind-Beziehungen, wo, wenn der übergeordnete Punkte, um das Kind und das Kind Punkte, die auf der übergeordneten, die Sie nie entlassen werden), die Sie manchmal brauchen die schwachen Referenzen. Auch, wenn Sie möchten, um einen Zeiger auf ein Objekt, das Sie nicht besitzen, aber wollen, dass es, um gültig zu sein nur so lange, wie es existiert, dann wollen Sie mit einem schwachen Zeiger, denn wenn er freigegeben ist, durch den Eigentümer, der Mauszeiger automatisch eingestellt nil und nicht zeigen zu Speicher, dass sollte es nicht sein.

    2. assign mit skalaren Werten, und ist der Standard-setter. copy macht Sinn, wenn Sie möchten, um automatisch eine Kopie des Objekts, und legen Sie den Zeiger auf die Kopie statt auf das ursprüngliche Objekt. Es macht nur Sinn, wenn Sie einen besonderen Bedarf (in der Regel, weil Sie nicht wollen, das Objekt zu mutieren, die auf Sie).

    3. Den link, den Sie zur Verfügung gestellt, die zeigt, dass __stark ist der Standard (und daher Sie don ' T brauchen, um es zu spezifizieren) bezieht sich auf Variablen und nicht zu deklarierten Eigenschaften. Die Standardeinstellung für die deklarierten Eigenschaften ist assign also es wird sicherlich einen Unterschied machen. Wenn Sie wollen assign jedoch macht es keinen Unterschied, ob Sie es angeben oder nicht (andere als nur klar zu sein, dass es das ist, was Sie wollte).
      BEARBEITEN: Aber, wie Jacques wies darauf hin, das ändert sich mit LLVM 3.1 und der Standard ist ändern von assign zu strong. In diesem Fall macht es absolut keinen Unterschied, ob oder nicht Sie geben strong und kann es weglassen, wenn Sie wollen. Ich persönlich denke, dass es gut ist, zu buchstabieren Sie es aus (vor allem, da es einen Konflikt gibt zwischen den verschiedenen Versionen), so dass jeder sich den code auf der gleichen Seite. Andere mögen widersprechen in diesem Punkt aber. 🙂

    Ich würde vorschlagen, das Lesen der Deklarierten Eigenschaften Abschnitt Die Objective-C Programmiersprache hier: <document removed by Apple with no direct replacement>.

    • Sie haben tatsächlich verändert die Standardeinstellungen für Eigenschaften, wie die nächste Version (3.1) von Clang: clang.llvm.org/docs/...
    • Interessant... Jetzt ist es anders zwischen ARC und nicht-ARC-code. Danke @JacquesCousteau!
    • Ich habe schon gelesen das der link, den Sie gab viele Male, leider finde ich es sehr leicht auf nützliche Informationen, die warum Frage ich hier. Zu Ihrer Antwort habe ich nicht das Gefühl, es richtet sich meine Frage in Bezug auf die readonly-Eigenschaften speziell.
    • Nun, ich antwortete auf die Frage (neben dem link), da fragte Sie es hier. 🙂 So weit meine Antwort, das alles hier gilt für die deklarierten Eigenschaften, ob Sie readonly oder nicht. Es gibt nichts besonderes über readonly, außer der Tatsache, dass ein setter werden nicht abgegeben, wenn du Sie mit @synthetisieren Sie.
    • Ich verstehe, dass aber die in Ihrer Antwort sagen Sie, dass die Kopie macht Sinn, in manchen Situationen, aber macht es überhaupt Sinn, für eine readonly-Eigenschaft? Ich bin schon verwirrt, deshalb habe ich gehofft zu begrenzen, dass die Erklärung des readonly-Eigenschaften.
    • Gotcha. Bei readonly-es in der Regel keine Rolle, da keine setter für Sie erstellt (das ist der einzige Ort, an dem es verwendet werden würde). Allerdings, wie @KenThomases wies darauf hin, Sie können deklarieren es als Lesen und schreiben und es würde einen Unterschied machen an diesem Punkt.
    • Ausgezeichnet. Also für eine readonly-Eigenschaft, kopieren===stark, bis zu dem Zeitpunkt, als Sie eine Unterklasse oder erweitern redeclare die Eigenschaft als readwrite (wie ich es verstehe).
    • Art. Kopieren ist einfach ignoriert, nur Lesen, bis dann. Und ja, die stark impliziert wird, so dass das, was Sie am Ende wit.
    • Dieser Artikel deckt vermutlich ähnlichen Themen, um die, die verschwunden: developer.apple.com/library/ios/documentation/cocoa/conceptual/...

    InformationsquelleAutor lnafziger
  2. 7

    Einen zusätzlichen Punkt: Eigenschaften bekommen können erneut deklariert von readonly zu readwrite. Zum Beispiel, eine Unterklasse kann eine nur-lese-Eigenschaft von der Superklasse, die Lesen und schreiben, ähnlich wie viele Cocoa-Klassen-Unterklassen hinzufügen Veränderbarkeit. Ebenso kann eine Eigenschaft sein, öffentlich zu Lesen-aber nur die class redeclare es Lesen-schreiben für den internen Gebrauch in eine Klasse Erweiterung. Also, wenn die Klasse stellt die eigene Immobilie kann es von Vorteil eine synthetisierte setter, der ist Speicher-management richtig und strahlt entsprechende Key-Value Observing Benachrichtigungen ändern.

    Wie die Dinge derzeit stehen, werden alle anderen Attribute, die die Eigenschaft haben, konsequent zu sein. Es ist denkbar, dass der compiler entspannen konnte diese Anforderung. (Einige halten es für einen Fehler.) Das ist sowieso ein Grund zu erklären readonly Eigentum mit Besitz-Attribut wie strong, copy oder schwach – so dass es passt auf die readwrite nochmaliges deklarieren einer anderswo.

    Hinsichtlich Ihrer Frage 3 sind, werden Sie gefragt, ob die Eigentums-qualifier-code wirkt sich auf die Aufrufe der getter? Nein, tut es nicht.

    • So der stark/schwach-Modifizierer macht keinen Unterschied,, um eine readonly-Eigenschaft anderes als eine änderung der lifetime-qualifier der synthetisierten ivar, ist das richtig?
    • Vielen Dank für Ihre Hilfe!
    InformationsquelleAutor Ken Thomases
  3. 0

    Diese 2 Zeilen code für mich arbeiten:

    .h-Datei:

    @property (nonatomic, readonly, copy) NSString *username;

    .m-Datei:

    @property (nonatomic, readwrite, copy) NSString *username;
    InformationsquelleAutor Golden Thumb
Schreibe einen Kommentar