Was will uns diese Analyzer Meldung sagen ?

  • Habe jetzt aber doch was gefunden das ich nicht verstehe:

    Quellcode

    1. +(NSData *)getData
    2. {
    3. NSData *data=[[[NSData alloc] init] autorelease];
    4. return data;
    5. }
    7. +(NSData*)copyData
    8. {
    9. NSData *data=[self getData];
    10. return data; << Object with +0 retain counts returned to caller where a +1 (owning) retain count is expected
    11. }
    Alles anzeigen


    Mir ist klar das ich ein Object ohne Retain übergebe, aber das ist ja auch richtig. Sonst hätte ich ja ein Leak. Die aufrufende Methode muss sich selber darum kümmern das er owner wird.
    Selbst wenn ich schreibe

    Quellcode

    1. +(NSData*)copyData
    2. {
    3. NSData *data=[[[self getData] retain] autorelease];
    4. return data;
    5. }


    bleibt die Warning erhalten.

    Wo ist jetzt mein Denkfehler ?

    Gruß

    Claus
    2 Stunden Try & Error erspart 10 Minuten Handbuchlesen.

    Pre-Kaffee-Posts sind mit Vorsicht zu geniessen :)

  • Thallius schrieb:

    Es geht also darum, dass Xcode erwartet das eine Funktion die mit copy anfängt auch ein retaintes Object zurückliefert. Da wäre ich jetzt nicht drauf gekommen.

    Danke

    Claus


    Der Analyzer, der Analyzer.

    Ich hatte letztens etwas ähnlich Doofes, nämlich rein aus Daffke 'create' im Methodennamen stehen.
    Und schon wurde gemeckert…
    I would be embarrassed if they did not spy on me.

  • Jo ich habe noch was nettes:

    Quellcode

    1. int *data=nil;
    2. if(usedata==YES)
    3. {
    4. data=malloc(200);
    5. }
    7. ...
    9. if(usedata)
    10. {
    11. int a=data[0]; << Array access (from variable 'data') results in a null pointer dereference
    12. }
    Alles anzeigen


    Gruß

    Claus
    2 Stunden Try & Error erspart 10 Minuten Handbuchlesen.

    Pre-Kaffee-Posts sind mit Vorsicht zu geniessen :)

  • macmoonshine schrieb:

    Thallius schrieb:

    Es geht also darum, dass Xcode erwartet das eine Funktion die mit copy anfängt auch ein retaintes Object zurückliefert. Da wäre ich jetzt nicht drauf gekommen.

    Das steht doch in den Speicherverwaltungsregeln genau erklärt. Der Analyzer kennt die (zumindest ein bisschen) ;)


    Hm also ich finde nicht das man aus den Rules automatisch implizieren kann, dass selbstgeschriebene Methoden sich an diese Semantik halten müssen.

    Gruß

    Claus
    2 Stunden Try & Error erspart 10 Minuten Handbuchlesen.

    Pre-Kaffee-Posts sind mit Vorsicht zu geniessen :)

  • Thallius schrieb:

    macmoonshine schrieb:

    Thallius schrieb:

    Es geht also darum, dass Xcode erwartet das eine Funktion die mit copy anfängt auch ein retaintes Object zurückliefert. Da wäre ich jetzt nicht drauf gekommen.

    Das steht doch in den Speicherverwaltungsregeln genau erklärt. Der Analyzer kennt die (zumindest ein bisschen) ;)


    Hm also ich finde nicht das man aus den Rules automatisch implizieren kann, dass selbstgeschriebene Methoden sich an diese Semantik halten müssen.

    Gruß

    Claus


    doch, genau das steht da:

    You take ownership of an object if you create it using a method whose name begins with ... “copy” ...

  • Thallius schrieb:

    Hm also ich finde nicht das man aus den Rules automatisch implizieren kann, dass selbstgeschriebene Methoden sich an diese Semantik halten müssen.

    Das ist kein Automatismus sondern eine Konvention. Du kannst sie brechen, aber musst dann auch mit den Ergebnissen leben. Der Analyzer hält sich an diese Konventionen.

    Diese Regeln machen die Speicherverwaltung jedenfalls wesentlich einfacher.
    „Meine Komplikation hatte eine Komplikation.“

  • Natürlich könnte man seine Methoden nennen wie man will, solange ausser Dir niemand mit den von Dir erstellten Klassen arbeiten muss. Allerdings gewöhnst Du Dir damit einen sehr "schlechten" Stil an, welcher Dir erhebliche Probleme bereiten wird, wenn Du mal in einem Team arbeitest, oder jemandem Deine Klassen zur Verfügung stellen möchtest.

    Ich und wohl auch jeder andere Objective-C Programmierer mit Kenntnis der Speicherverwaltungsregeln erwartet von einer Methode mit dem Namen copyXXX, dass dort ein Objekt mit einem retainCount + 1 zurückgegeben wird, welchem ich release schicken muss, wenn ich es nicht mehr benötige. Wenn dort jetzt ein Autoreleased Objekt zurück kommt, wird es irgendwo knallen und man sucht sich einen "Wolf", weil man überzeugt ist die Methode copyXXX richtig verwendet zu haben.

    Also lieber mit einem "guten" Stil programmieren und die Speicherverwaltungsregeln und Namens-Konventionen einhalten. ;)

  • MCDan schrieb:

    Natürlich könnte man seine Methoden nennen wie man will, solange ausser Dir niemand mit den von Dir erstellten Klassen arbeiten muss. Allerdings gewöhnst Du Dir damit einen sehr "schlechten" Stil an, welcher Dir erhebliche Probleme bereiten wird, wenn Du mal in einem Team arbeitest, oder jemandem Deine Klassen zur Verfügung stellen möchtest.

    Nicht nur im Team, auch alleine, nach 3 Monaten. Mir ist letztens aufgefallen, dass ich immer mehr Zeit damit zubringe, Sachen gut und konsistent zu benennen. Im Endeffekt spart es Zeit. Und wenn man Probleme hat, eine passende Benennung zu finden, ist meistens der Wurm im Konzept.
    Multigrad - 360°-Produktfotografie für den Mac

  • Thallius schrieb:

    Es geht also darum, dass Xcode erwartet das eine Funktion die mit copy anfängt auch ein retaintes Object zurückliefert. Da wäre ich jetzt nicht drauf gekommen.

    Danke

    Claus

    So sind die Namens-- und Speicherverwaltungsregeln. :-]

    Übrigens gibt es auch eine Regel für get…
    Es hat noch nie etwas gefunzt. To tear down the Wall would be a Werror!
    25.06.2016: [Swift] gehört zu meinen *Favorite Tags* auf SO. In welcher Bedeutung von "favorite"?

  • mattik schrieb:

    MCDan schrieb:

    Natürlich könnte man seine Methoden nennen wie man will, solange ausser Dir niemand mit den von Dir erstellten Klassen arbeiten muss. Allerdings gewöhnst Du Dir damit einen sehr "schlechten" Stil an, welcher Dir erhebliche Probleme bereiten wird, wenn Du mal in einem Team arbeitest, oder jemandem Deine Klassen zur Verfügung stellen möchtest.

    Nicht nur im Team, auch alleine, nach 3 Monaten. Mir ist letztens aufgefallen, dass ich immer mehr Zeit damit zubringe, Sachen gut und konsistent zu benennen. Im Endeffekt spart es Zeit. Und wenn man Probleme hat, eine passende Benennung zu finden, ist meistens der Wurm im Konzept.

    Ich spreche ja immer davon, dass ein anderer im Sinne dieser Regeln auch man selbst nach gewisser Zeit ist.
    Es hat noch nie etwas gefunzt. To tear down the Wall would be a Werror!
    25.06.2016: [Swift] gehört zu meinen *Favorite Tags* auf SO. In welcher Bedeutung von "favorite"?

  • Naja wenigstens schön, das ich euch in eurer Einigkeit so bestärken konnte :)

    BTW irgendwie versteht ihr mich eh immer alle falsch. Nur weil ich nicht immer alles sofort schlucke heißt das ja nicht das ich mir die Regeln nicht annehme.

    Gruß

    Claus

    P.S. ich programmiere jetzt aus Trotz nur noch in Detusch. Dann kann ich mit

    -(NSData*)Kopiere

    machen was ich will :D
    2 Stunden Try & Error erspart 10 Minuten Handbuchlesen.

    Pre-Kaffee-Posts sind mit Vorsicht zu geniessen :)

  • Thallius schrieb:

    Naja wenigstens schön, das ich euch in eurer Einigkeit so bestärken konnte :)

    BTW irgendwie versteht ihr mich eh immer alle falsch. Nur weil ich nicht immer alles sofort schlucke heißt das ja nicht das ich mir die Regeln nicht annehme.

    Gruß

    Claus

    P.S. ich programmiere jetzt aus Trotz nur noch in Detusch. Dann kann ich mit

    -(NSData*)Kopiere

    machen was ich will :D


    und -(void)ändere, -(void)mülle etc