Speicherverwaltung und CLANG: -*copy im Methodennamen -> wem gehört's?

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • Speicherverwaltung und CLANG: -*copy im Methodennamen -> wem gehört's?

    Moin,

    ich habe ja irgendwann mal gelernt, dass mir jedes Objekt gehört, dass ich mit -init* oder -*copy erzeuge.
    Dem scheint so nicht ganz zu stimmen.

    Habe gerade in einer Kategorie NSArray und NSDictionary um -mutableDeepCopy erweitert, weil es mir doch arg zu mühsam und fehleranfällig erscheint, das jedes Mal von Hand tippen zu müssen.

    Der Static Analyzer von Clang geht davon aus, dass -mutableDeepCopy ein Objekt zurück gibt, welches mir als Aufrufer nicht gehört. Bei -mutableCopy geht er jedoch wie gewohnt davon aus, dass mir das Objekt gehört.

    Abgesehen von einem Hinweis in der Headerdatei, dass mir das von -mutableDeepCopy erzeugte Objekt eben doch nicht gehört: Wie kann ich das Dilemma lösen?

    Die Methoden in -mutable*WithMutableMembers umbenennen?
    Wäre schon geiler, wenn das gleich hieße. Da die mutableDeepCopy Methoden halt auch die mutableDeepCopy Methoden der jeweils anderen Collection aufrufen wollen und eventuell noch einmal NSSet als weitere Collection hinzukommt, ist das so einfach simpler zu implementieren.

    Verwirrte Grüße aus Hamburch!
    «Applejack» "Don't you use your fancy mathematics to muddle the issue!"

    Iä-86! Iä-64! Awavauatsh fthagn!

    kmr schrieb:

    Ach, Du bist auch so ein leichtgläubiger Zeitgenosse, der alles glaubt, was irgendwelche Typen vor sich hin brabbeln. :-P
  • Und woher weiß der Analyzer dann, wem das Objekt gehört?
    Oder, anders gefragt: wie erklärst Du dem Static Analyzer, dass Deine Methode ein Objekt übergibt, dessen Ownership beim Empfänger liegt?
    «Applejack» "Don't you use your fancy mathematics to muddle the issue!"

    Iä-86! Iä-64! Awavauatsh fthagn!

    kmr schrieb:

    Ach, Du bist auch so ein leichtgläubiger Zeitgenosse, der alles glaubt, was irgendwelche Typen vor sich hin brabbeln. :-P
  • gritsch schrieb:

    warum? bei mutableDeepCopy geht man doch davon aus dass es sich verhält wie copy oder eben mutableCopy.

    Der Name entspricht aber eben nicht mehr den Speicherverwaltungsregeln, was anderen Entwicklern dann schon Kopfzerbrechen bereiten kann. Rchtig schlimm wird es, wenn dann fallweise Annotations verwendet werden oder man versucht, die Regeln durch weitere Namensregeln aufzubohren.
    „Meine Komplikation hatte eine Komplikation.“
  • macmoonshine schrieb:

    Der Name entspricht aber eben nicht mehr den Speicherverwaltungsregeln, was anderen Entwicklern dann schon Kopfzerbrechen bereiten kann.

    Klar kann man die Methodensignatur - (id) meinSupergeilesMegaObjekt benutzen.
    Man kann auch let apples = "pears" machen.

    Dann muss man sich auch nicht wundern, dass sich andere Entwickler durch ein positives apples == "pears" verwirrt fühlen.

    Ob die Methodensignatur jetzt - (id) mutableDeepCopy oder - (id) mutableCopyDeep oder - (id) deepMutableCopy heißt, ändert nichts an meinem (offensichtlich veraltetem oder gar falschen) Verständnis der Speicherverwaltungsregeln:
    - Methoden, die mit init* oder new* beginnen, liefern Objekte, die mir gehören.
    - Methoden, die *copy* beinhalten, liefern Objekte, die mir gehören.

    Oder vice versa:
    - Methoden, die Objekte liefern sollen, welche dem Aufrufer gehören, müssen mit init* oder new* beginnen beziehungsweise *copy* beinhalten.

    Offenbar habe ich die Regeln fehlinterpretiert und sie heißen mindestens seit 2012 eigentlich:
    - Methoden, die mit init*, new*, copy* oder mutableCopy* beginnen, liefern Objekte, die mir gehören.

    Oder vice versa:
    - Methoden, die Objekte liefern sollen, welche dem Aufrufer gehören, müssen mit init*, new*, copy* oder mutableCopy* beginnen.

    Insofern sind natürlich Verwirrungen und Aufwand geringer, wenn ich mir einfach an diese Namenskonvention ins Gehirn brenne.
    «Applejack» "Don't you use your fancy mathematics to muddle the issue!"

    Iä-86! Iä-64! Awavauatsh fthagn!

    kmr schrieb:

    Ach, Du bist auch so ein leichtgläubiger Zeitgenosse, der alles glaubt, was irgendwelche Typen vor sich hin brabbeln. :-P
  • macmoonshine schrieb:

    gritsch schrieb:

    warum? bei mutableDeepCopy geht man doch davon aus dass es sich verhält wie copy oder eben mutableCopy.

    Der Name entspricht aber eben nicht mehr den Speicherverwaltungsregeln, was anderen Entwicklern dann schon Kopfzerbrechen bereiten kann. Rchtig schlimm wird es, wenn dann fallweise Annotations verwendet werden oder man versucht, die Regeln durch weitere Namensregeln aufzubohren.


    warum sollte es einen programmierer interessieren? das interessiert doch nur den compiler (in zeiten von ARC). oder verstehe ich jetzt irgendwas falsch?
  • Ich weiß nicht, ob ARC mit 'dem Aufrufer gehörenden' Objekten anders umspringt als mit 'dem Aufrufer nicht gehörenden' Objekten.

    Im Prinzip macht ARC ja dasselbe wie MRR + Static Analyzer.
    Und der Static Analyzer trifft Annahmen zum Memory Management gemäß der Speicherverwaltungsregeln.
    «Applejack» "Don't you use your fancy mathematics to muddle the issue!"

    Iä-86! Iä-64! Awavauatsh fthagn!

    kmr schrieb:

    Ach, Du bist auch so ein leichtgläubiger Zeitgenosse, der alles glaubt, was irgendwelche Typen vor sich hin brabbeln. :-P
  • Wie konnte ich diesen Thread verpassen?

    In der Tat, Gritsch hat weitest gehend Recht: Das interessiert nur den Compiler (und den, der mit MRC arbeitet, muuuaaaahahahahahah). Genau genommen ist es sogar so, dass sämtliche dieser Regeln in ARC überhaupt nur noch deshalb existieren, um kompatibel mit MRC zu sein. Ein Compiler, der nur mit ARC läuft, könnte es sich ganz einfach machen. Ownership-Transfer. Immer. Und das gilt dann auch für den Programmierer mit ARC: Interessiere dich nicht dafür. (Geht ja auch gar nicht. Wie sollte man sich dafür interessieren? Mit retain? release?)

    Aber auch macmoonshine hat in gewisser Weise Recht: es kann interessant sein, ob es im ARP liegt. Dabei gibt es zwei Interessen:

    1. Speicherperformance. Allerdings ist hier die "oberste" Nachricht gar nicht soo interessant, da ja in der Methode auch ARP benutzt werden kann.

    2. Ich habe tatsächlich mal (gewollt) einen Fall bauen können, bei dem es eine Rolle spielte. Ich müsste es nachschauen. Der Trick lag irgendwie darin, in einem Ausdruck Objekte wild zu erzeugen und wieder freizugeben und dabei dem retain von ARC zuvorzukommen. Damit das überhaupt funktionierte und nicht undefinierter Code war, musste man den C-Standard 5 Mal lesen. Völlig absurder Fall.

    Kurzer Rede langer Sinn: Was Gritsch sagt, stimmt schon: Was interessierst du dich überhaupt dafür?
    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"?
  • Amin Negm-Awad schrieb:

    Was interessierst du dich überhaupt dafür?

    Damals™ gehörte der Static Analyzer zum Tool der Wahl um den Code auf logische Fehler zu prüfen. Das hat sich seit damals™ nicht geändert.
    Und dieses spezielle Projekt benutzt nach wie vor MRR.

    Darum interessiert mich das.
    «Applejack» "Don't you use your fancy mathematics to muddle the issue!"

    Iä-86! Iä-64! Awavauatsh fthagn!

    kmr schrieb:

    Ach, Du bist auch so ein leichtgläubiger Zeitgenosse, der alles glaubt, was irgendwelche Typen vor sich hin brabbeln. :-P