objective-c: @property (retain) (sonstige Sprachen, auch PHP)

[thread]14682[/thread]

objective-c: @property (retain)

Leser: 15

Articles: hide open all | hide show old branches

+8 replies
esskar

2010-02-16 19:00
User since
2003-08-04
7321 Artikel
ModeratorIn
hi.

hab ne Klasse
Code: (dl )

1 2 3 4 5 6 7 8

@interface Foo : NSObject { id bar; } @property (readwrite, retain) bar; @end
und die implementierung
Code: (dl )

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26

@implementaion Foo @synthesize bar; - (id)init { if(self = [super init]) { Bar *b = [[Bar alloc] init]; self.bar = b; [b release]; } return self; } - (void)dealloc { if(self.bar) { [self.bar release]; self.bar = nil; } [super dealloc]; } @end
meine frage zu dealloc:
kann ich das so schreiben, oder wird durch die verwendung von
Code: (dl )

self.bar
der referenz zeiger von bar hoch gezählt.
ich weiss, dass ich auch nur
Code: (dl )

if(bar) ...
schreiben könnt, aber ich finde, so sieht man direkt, dass ein direkter member gemeint ist.
- +7 replies
- murphy
  
  2010-02-16 19:30
  
  User since
  2004-07-19
  1776 Artikel
  HausmeisterIn
  
  Du gibst die Referenz auf das frisch erzeugte Objekt der Klasse Bar direkt im Konstruktor von Foo mit - release wieder frei, lässt den ungültigen Zeiger aber in einer Instanzvariablen herumliegen und rufst im Destruktor von Foo noch einmal - release darauf auf.
  
  Wenn Dich hier nicht die passenden Compilerflags zum Anschalten der Garbagecollectionruntime retten, die dafür sorgen, dass - retain und - release nichts mehr tun, dafür aber die Inhalte von Instanzvariablen mit Zeigertypen automatisch verfolgt werden, dann sollte Dir dieses Programm früher oder später um die Ohren fliegen ;-)
  When C++ is your hammer, every problem looks like your thumb.
  - +2 replies
  - esskar
    
    2010-02-16 19:50
    
    User since
    2003-08-04
    7321 Artikel
    ModeratorIn
    
    das hätt ich auch so gesehen. als C programmierer denk ich auch ab und an auch so. aber siehe http://cocoadevcentral.com/d/learn_objectivec/ (Properties)
    
    das (retain) vor der property sorgt dafür, dass der setter der bar property das value retained. aber laut der seite eben wohl auch nur der setter. somit sollte der getter nur das object zurück geben ohne es zu retainen.
    - murphy
      
      2010-02-16 20:06
      
      User since
      2004-07-19
      1776 Artikel
      HausmeisterIn
      
      Es entspricht auch der gängigen Praxis bei Objective C, dass die Verantwortung der Speicherverwaltung mit wenigen Ausnahmen immer bei der aufgerufenen Methode liegt.¹ Daher sind Rückgabewerte normalerweise nicht retained, damit man sich als Programmierer zum Beispiel nicht weiter um sie kümmern muss, wenn man sie gar nicht abspeichert.
      
      Damit es überhaupt möglich ist, Speichermanagement mit Referenzzählern zu betreiben bei dem die Zähler der Rückgabewerte nicht explizit dekrementiert werden müssen, gibt es bei Objective C Autoreleasepools, denen man Objekte hinzufügen kann, die man zurückgibt und deren Referenzzähler "später mal" noch dekrementiert werden muss. Der Normalfall ist, dass mindestens ein solcher Pool installiert ist und am Ende jedes Durchlaufes der Hauptereignisschleife des Programmes einmal geleert wird.
      
      ¹ Ausnahmen sind praktisch ausschließlich die explizit zur Speicherverwaltung gedachten Methoden wie + alloc, - copy und dergleichen mehr.
      When C++ is your hammer, every problem looks like your thumb.
  - +4 replies
  - murphy
    
    2010-02-16 19:56
    
    User since
    2004-07-19
    1776 Artikel
    HausmeisterIn
    
    Ups, ich sehe erst jetzt, dass Du ja nicht die Syntax self->bar sondern self.bar benutzt. Diese neue Syntax erzeugt aber gar keine Instanzvariablenzugriffe, sondern Eigenschaftsakzessorenzugriffe!
    
    Damit ist das, was ich in meinem letzten Beitrag schrieb Unfug: Der Konstruktor deiner Klasse Foo ist korrekt, der Destruktor aber nicht, weil er zweimal - release aufruft — einmal explizit und einmal implizit im Eigenschaftssetzer, denn dieser gibt natürlich den alten Wert der Eigenschaft frei, nachdem er den neuen abgespeichert hat.
    When C++ is your hammer, every problem looks like your thumb.
    - +3 replies
    - esskar
      
      2010-02-16 20:04
      
      User since
      2003-08-04
      7321 Artikel
      ModeratorIn
      
      also dann doch nur?
      
      Code: (dl )
      
      1 2 3 4 5 6 7 8 9
      
      - (void)dealloc { if(bar) { [bar release]; bar = nil; } [super dealloc]; }
      
      man ist das hässlich >)
      - +2 replies
      - murphy
        
        2010-02-16 20:18
        
        User since
        2004-07-19
        1776 Artikel
        HausmeisterIn
        
        Warum nicht so:
        
        Code: (dl )
        
        1 2 3 4 5 6 7
        
        - (void)dealloc { if(self.bar) self.bar = nil; [super dealloc]; }
        
        Und der Konstruktor geht natürlich auch hübscher, denn man weiß ja, dass dort die Instanzvariablen noch nicht belegt sind, also kann man auch das hier schreiben:
        
        Code: (dl )
        
        1 2 3 4 5 6 7
        
        - (id)init { if(self = [super init]) bar = [[Bar alloc] init]; return self; }
        
        Ich persönlich finde es sogar besser, im Konstruktor noch keine Eigenschaftssetzer aufzurufen. Mir ist nämlich nicht wohl dabei, mich darauf zu verlassen, dass die Eigenschaften vom Allokator auf nil initialisiert wurden, und wären sie das nicht, würde der Aufruf der Setzmethoden versuchen die zufälligen Pointer in den Instanzvariablen als Objekte zu behandeln, denen man - release Nachrichten schicken muss, nachdem man die neuen Werte eingetragen hat...
        When C++ is your hammer, every problem looks like your thumb.
        
        esskar
        
        2010-02-16 21:23
        
        User since
        2003-08-04
        7321 Artikel
        ModeratorIn
        
        ah, so meinst du. danke.

View all threads created 2010-02-16 19:00.