Unklarheiten bei autorelease ???

  • Unklarheiten bei autorelease ???

    Hallo ihr,
    verdammt ... vielleicht könnt ihr mir erklären, warum das RC des Objekts nicht um 1 erhöht wurde, nachdem retain an diesem Objekt geschickt wurde?

    Hier Codeauszüge:

    worker.h

    C-Quellcode

    1. #ifndef _WORKER_H_
    2. #define _WORKER_H_
    4. #include <Foundation/Foundation.h>
    6. @interface Worker : NSObject
    7. {
    8. NSString * _lastname;
    9. NSString * _firstname;
    10. int _age;
    11. }
    13. +(Worker *)createWorker:(NSString*)lastname firstname:(NSString*)firstname age:(int)age;
    15. -(id)init;
    17. -(void)setLastname:(NSString *)lastname;
    18. -(void)setFirstname:(NSString *)firstname;
    19. -(void)setAge:(int)age;
    21. -(NSString *)lastname;
    22. -(NSString *)firstname;
    23. -(int)age;
    26. @end
    28. #endif // _WORKER_H_
    Alles anzeigen


    worker.m

    Quellcode

    1. #include "worker.h"
    3. @implementation Worker
    5. // CA
    6. +(Worker *)createWorker:(NSString*)lastname firstname:(NSString*)firstname age:(int)age
    7. {
    8. Worker * worker = [[[Worker alloc] init] autorelease];
    9. [worker setLastname:lastname];
    10. [worker setFirstname:firstname];
    11. [worker setAge:age];
    12. return worker;
    13. }
    15. -(id)init
    16. {
    17. [super init];
    18. _lastname = [[NSString alloc] init];
    19. _firstname = [[NSString alloc] init];
    20. _age = 0;
    21. return self;
    22. }
    24. // speicher freigeben
    25. -(void)dealloc
    26. {
    27. NSLog(@"dealloc von Klasse worker");
    28. [_lastname release];
    29. [_firstname release];
    30. [super dealloc];
    31. }
    33. -(void)setLastname:(NSString *)lastname
    34. {
    35. [lastname retain];
    36. [_lastname release];
    37. _lastname = lastname;
    38. }
    40. -(void)setFirstname:(NSString *)firstname
    41. {
    42. [firstname retain];
    43. [_firstname release];
    44. _firstname = firstname;
    45. }
    47. -(void)setAge:(int)age
    48. {
    49. _age = age;
    50. }
    52. -(NSString *)lastname
    53. {
    54. return _lastname;
    55. }
    57. -(NSString *)firstname
    58. {
    59. return _firstname;
    60. }
    62. -(int)age
    63. {
    64. return _age;
    65. }
    67. @end
    Alles anzeigen


    main.m

    C-Quellcode

    1. #include <Foundation/Foundation.h>
    2. #include "worker.h"
    4. int main(int argc, const char *argv[])
    5. {
    6. NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];
    8. // dieses objekt wird zum ARP hinzufügt (CA)
    9. Worker * worker1 = [Worker createWorker:@"Mustermann" firstname:@"Fritz" age:44];
    11. NSString * lastname = [[worker1 lastname] retain];
    12. NSString * lastname_copy = lastname;
    14. NSLog(@"retainCount for lastname_copy: %i", [lastname_copy retainCount]);
    15. NSLog(@"retainCount for lastname: %i", [lastname retainCount]);
    17. [pool release];
    18. return 0;
    19. }
    Alles anzeigen


    Das retainCount von lastname sollte eigentlich 2 sein? oder?
    Sonst hätte ich das Prinzip verstanden, oder?
    Aus macfreakz wurde Apfelbeisser …

  • Hm,...

    habe gerade keinen Mac zur Hand, um Dein Programm mal zu testen. X(

    Wenn ich jetzt nicht falsch liege, dann gibt es bei Konstanten, also @"Mustermann", retain/release überhaupt nicht, bzw. funktioniert dies dort nicht. Die Konstanten bleiben zur kompletten Laufzeit des Programms erhalten und sollten einen retainCount von -1 haben. Über dieses Problem bin ich auch mal gestolpert und hoffe, dass ich es noch richtig, wie oben beschrieben, in Erinnerung habe. ?(

    Versuche doch mal stat @"Mustermann"

    Quellcode

    1. [NSString stringWithString:@"Mustermann"]
    zu verwenden, damit der String autom. im Autorelease-Pool steht.

  • Habe diesen Block überarbeitet:

    Quellcode

    1. // CA
    2. +(Worker *)createWorker:(NSString*)lastname firstname:(NSString*)firstname age:(int)age
    3. {
    4. Worker * worker = [[[Worker alloc] init] autorelease];
    6. NSString * lastname_no = [NSString stringWithString:lastname];
    7. NSString * firstname_no = [NSString stringWithString:firstname];
    9. [worker setLastname:lastname_no];
    10. [worker setFirstname:firstname_no];
    11. [worker setAge:age];
    13. [lastname_no release];
    14. [firstname_no release];
    16. return worker;
    17. }
    Alles anzeigen

    Alles funktioniert richtig ... danke, McDan!!!
    So, jetzt liege ich an einem Problem zur meinen Vorstellung, wie man Objekt "behalten" kann, nachdem das AutoreleasePool entfernt wurde:

    Quellcode

    1. NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];
    3. // dieses objekt wird zum ARP hinzufügt (CA)
    4. Worker * worker1 = [Worker createWorker:@"Spillner" firstname:@"Fabian" age:21];
    6. NSString * lastname = [worker1 lastname];
    7. [lastname retain];
    8. NSString * lastname2 = lastname;
    10. NSLog(@"retainCount for lastname: %i", [lastname retainCount]);
    11. NSLog(@"retainCount for lastname2: %i", [lastname2 retainCount]);
    13. NSLog(@"retainCount von lastname2 nach release von pool: %i", [lastname retainCount]);
    14. NSLog(@"%@", lastname2);
    16. [pool release];
    18. NSLog(@"%@", lastname2); // geht nicht
    Alles anzeigen


    es ist schon klar, dass lastname2 nach Release von pool nicht verwendet werden kann. Aber wie muss man vorgehen, damit lastname2 nach dem Release von pool verwendet werden kann?
    Aus macfreakz wurde Apfelbeisser …

  • Original von macfreakz

    Quellcode

    1. // CA
    2. +(Worker *)createWorker:(NSString*)lastname firstname:(NSString*)firstname age:(int)age
    3. {
    4. Worker * worker = [[[Worker alloc] init] autorelease];
    6. NSString * lastname_no = [NSString stringWithString:lastname];
    7. NSString * firstname_no = [NSString stringWithString:firstname];
    9. [worker setLastname:lastname_no];
    10. [worker setFirstname:firstname_no];
    11. [worker setAge:age];
    13. [lastname_no release];
    14. [firstname_no release];
    16. return worker;
    17. }
    Alles anzeigen

    Alles funktioniert richtig ...

    Nein, tut es nicht! Du darfst lastname_no und firstname_no hier nicht releasen, weil Du sie mit einem Convenience Allocator erzeugt hast. Sie sind also bereits "autoreleased".

    Original von macfreakz
    So, jetzt liege ich an einem Problem zur meinen Vorstellung, wie man Objekt "behalten" kann, nachdem das AutoreleasePool entfernt wurde:

    [... hier war der Code ...]

    es ist schon klar, dass lastname2 nach Release von pool nicht verwendet werden kann. Aber wie muss man vorgehen, damit lastname2 nach dem Release von pool verwendet werden kann?

    Du musst einfach dafür sorgen, dass der retain-Counter um eins höher ist, als Referenzen auf das Objekt im Autoreleasepool sind. Dabei musst Du im Auge behalten, dass es zu jedem -retain auch ein -release oder -autorelease gibt.

    Michael

  • @Michael: danke für deinen Hinweis! Hat mir viel geholfen! Die letzten Zeilen sind mir schon klar.

    Quellcode

    1. NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];
    3. // dieses objekt wird zum ARP hinzufügt (CA)
    4. Worker * worker1 = [Worker createWorker:@"Spillner" firstname:@"Fabian" age:21];
    6. NSString * lastname = [worker1 lastname];
    7. NSString * lastname2 = lastname;
    8. [lastname2 retain]; // RC um 1 erhöhen für weitere Verwendung, nachdem ARP released wird.
    10. NSLog(@"retainCount for lastname: %i", [lastname retainCount]);
    11. NSLog(@"retainCount for lastname2: %i", [lastname2 retainCount]);
    13. [pool release];
    15. NSLog(@"retainCount for lastname: %i", [lastname retainCount]); // RC beträgt 1
    16. NSLog(@"%@", lastname2);
    17. [lastname2 release]; // lastname2 löschen
    Alles anzeigen


    Hier konnte das Programm erfolgreich beendet werden.
    Gibt es noch etwas zu beachten bei meinem Code?
    Aus macfreakz wurde Apfelbeisser …

  • Quellcode

    1. // CA
    2. +(Worker *)createWorker:(NSString*)lastname firstname:(NSString*)firstname age:(int)age
    3. {
    4. Worker * worker = [[[Worker alloc] init] autorelease];
    6. NSString * lastname_no = [NSString stringWithString:lastname];
    7. NSString * firstname_no = [NSString stringWithString:firstname];
    9. [worker setLastname:lastname_no];
    10. [worker setFirstname:firstname_no];
    11. [worker setAge:age];
    13. [lastname_no release];
    14. [firstname_no release];
    16. return worker;
    17. }
    Alles anzeigen


    Ich frage mich an der Stelle, warum man hier ueberhaupt String aus den Parametern initialisieren muss/sollte.

    Wuerde nicht ein:

    Quellcode

    1. ...
    2. [worker setLastname:lastname];
    3. [worker setFirstname:firstname];
    4. ...

    reichen? Dann koennte man sich die lokalen Variablen sparen und braeuchte sie natuerlich auch nicht zu releasen.

    so long

  • RE: Unklarheiten bei autorelease ???

    Wow, das ist ja mal alles sehr sauber programmiert. Das Prinzip hast du sicher verstanden. Ich würde die Accessoren paarweise schreiben. Aber das ist sicher Geschmackssache.

    Oben die Source schaue ich mir noch einmal an. In der Tat sehe ich auf den ersten Blick auch nicht, warum der RC nicht zwei sein sollte.

    ++ UDPATE ++
    Habe ich gerade in einer andern Antwort gesehen. IN der Tat hast du ja lediglich ein Const-Objekt. Das hat keinen richtigen RC.
    ++ /UPDATE ++

    Noch ein Verbesserungsvorschlag: Im dealloc kannst du statt eines weiteren releases ein -setKastname(Worker) machen. Dann hast du gar keine retains/releases mehr in deinem code. Das geht. Schau es dir an:

    Du hast:

    Quellcode

    1. [_lastname release];


    Daraus wird

    Quellcode

    1. [self setLastname:nil]
    2. ->
    3. [nil retain]; // ist asdrücklich erlaubt und hat keine Wirkung
    4. [_lastname release]; // das, was du wolltest
    5. _lastname = nil; // ist damit auch gleich erledigt.


    Außerdem solltest du noch den CA nicht +createWorker nennen, sondern +workerWith...
    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"?

  • RE: Unklarheiten bei autorelease ???

    Original von Tom9811
    Wow, das ist ja mal alles sehr sauber programmiert.

    Ja, sehr sauber programmiert. Dennoch kann man unerwartete Ergebnisse bekommen. Die Setter-Methoden für die Strings würde ich so niemals implementieren (auch wenn Du mich jetzt vierteilen wirst, Tom ;)), sondern so:

    Quellcode

    1. -(void)setLastname:(NSString *)lastname
    2. {
    3. [_lastname autorelease];
    4. _lastname = [lastname copy];
    5. }

    Begründung: man probiere einfach mal folgende main-Funktion mit der sauber programmierten Worker-Klasse aus:

    Quellcode

    1. int main (int argc, const char * argv[])
    2. {
    3. NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];
    5. NSMutableString *tempString = [NSMutableString stringWithString:@"Mustermann"];
    6. Worker *worker = [Worker createWorker:tempString firstname:@"Hans" age:30];
    8. NSLog(@"Nachname vom Worker: %@", [worker lastname]);
    10. [tempString appendString:@" - Ups, das sollte nicht sein"];
    12. NSLog(@"Nachname hat sich geaendert: %@!", [worker lastname]);
    14. [pool release];
    15. return 0;
    16. }
    Alles anzeigen

    Michael

  • RE: Unklarheiten bei autorelease ???

    Gegen das Kopie habe ich nichts. Das ist ja Frage des Inhaltes. Manchmal will man das, manchmal will man das nicht. Gegen das autorelease habe ich schon etwa. Da wird sich mancher User wundern, wenn er auf einmal einen autorelease auf seinem Objekt hat. :)

    Naja, vielleicht liest er ja vor jeder Benutzung einer Methode ausführlich die nicht-existierende Beschreibung und weiß es dann. ;)

    Ansonsten würde ich das in der Tat gar nicht so programmieren, sondern so:

    Quellcode

    1. Worker* worker = [Worker createWorker:[NSMutableString StringWithString:@"Mustermann"] firstname:@"Hans" age:30];
    3. NSLog(@"Nachname vom Worker: %@", [worker lastname]);
    5. [[worker lastName] appendString:@" - Ups, das sollte nicht sein"];
    7. NSLog(@"Nachname hat sich geaendert: %@!", [worker lastname])


    Der Fehler -was heißt hier Fehler- ist, dass du ein und dasselbe Objekt merhmals verzeigerst. Das tut man schon wegen dangling Pointern nicht. Ganz böse(tm). Aber gevierteilt wird da niemand.

    Wenn du im _main_ tatsächlich eine Kopie willst, dann sollte _main_ die anfertigen und sich nicht darauf verlassen, dass die gekapselte Worker-Klasse das macht. Damit hebst du die Kapselung auf. Also:


    Quellcode

    1. Worker* worker = [Worker createWorker:[NSMutableString StringWithString:@"Mustermann"] firstname:@"Hans" age:30];
    3. NSLog(@"Nachname vom Worker: %@", [worker lastname]);
    5. // _ICH_ will eine Kopie, also lege _ICH_ eine Kopie an.
    6. NSString* temp = [[self lastname] copy];
    7. [temp appendString:@" - Ups, das soll sein"];
    9. NSLog(@"Nachname hat sich nicht geändert: %@!", [self lastname] )


    Machst du eigentlich jedesmal Kopien? Gibt das nicht Ärger mit den Bindings?
    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"?

  • RE: Unklarheiten bei autorelease ???

    Doch, ich habe nochmal darüber nachgedacht und würde dich vierteilen.

    1. KVO kann so eigentlich nicht funktionieren, da ein anderes Objekt beobachtet wird als gespeichert ist.
    2. Damit gilt: Tschöööö ihr Bindings.
    3. Du hast jedesmal eine Kopie. Damit hebelst du RC eigentlich komplett aus. Wieviel. Speicher hat deine Kiste?

    Rest war Blödsinn, ich hatte mich verlesen.

    BTW: Diese Setter sind nicht von mir. Am Ende menes Artikels gibt es nochmal einen Link.
    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"?

  • RE: Unklarheiten bei autorelease ???

    Nächstes Problem:

    4. Du hast ein Array von Angestellten. Du hast ein Array von Projekten. Jedes Projekt hat einen Leiter. Wenn du jetzt von dem Projekt auf einen Angestellten als Leiter verweist, wird be einem Kopie ein neues Employee-Objekt angelegt. Ändert sich dort etwas (Name durch HEirat, Adresse durch Umzug usw. usf.) so sind die Daten des Projektleiters ungültig. Du musst also nachhalten und neu kopieren.

    Dann hast du Abteilunggen, die wiederum auf Angestellte verweisen. Auch hier muss alles nachgehalten werden.

    Dann hast du Tarifgruppen usw usf.

    Das ganze wird ein einziges riesiges unwartbares Wollknäuel.
    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"?

  • RE: Unklarheiten bei autorelease ???

    Original von Tom9811
    Gegen das Kopie habe ich nichts. Das ist ja Frage des Inhaltes. Manchmal will man das, manchmal will man das nicht. Gegen das autorelease habe ich schon etwa. Da wird sich mancher User wundern, wenn er auf einmal einen autorelease auf seinem Objekt hat. :)

    Wieso sollte sich jemand drüber wundern? Das -autorelease geht auf die Instanzvariable in dem Objekt und ist das "Gegenstück" zum -copy in der Setter-Methode. Ohne hätte man ein Speicherleck. Will ein User den Inhalt der Instanzvariable, den er sich über die Getter-Methode geholt hat, länger verwenden, hat er selbst für das "Überleben" zu sorgen.

    Original von Tom9811
    Naja, vielleicht liest er ja vor jeder Benutzung einer Methode ausführlich die nicht-existierende Beschreibung und weiß es dann. ;)

    Lies Dir mal z.B. die Doku zu -setTitle: von NSWindow durch und vergleiche das Verhalten von NSWindow mit dem der Klasse Worker.

    Original von Tom9811
    Ansonsten würde ich das in der Tat gar nicht so programmieren, sondern so:

    Quellcode

    1. Worker* worker = [Worker createWorker:[NSMutableString StringWithString:@"Mustermann"] firstname:@"Hans" age:30];
    3. NSLog(@"Nachname vom Worker: %@", [worker lastname]);
    5. [[worker lastName] appendString:@" - Ups, das sollte nicht sein"];
    7. NSLog(@"Nachname hat sich geaendert: %@!", [worker lastname])


    Der Fehler -was heißt hier Fehler- ist, dass du ein und dasselbe Objekt merhmals verzeigerst. Das tut man schon wegen dangling Pointern nicht. Ganz böse(tm). Aber gevierteilt wird da niemand.

    Du hast hier den "Fehler" gemacht, das Fehlverhalten nach zu programmieren. Genau dieses Verhalten will ich ja gar nicht haben.

    Original von Tom9811
    Wenn du im _main_ tatsächlich eine Kopie willst, dann sollte _main_ die anfertigen und sich nicht darauf verlassen, dass die gekapselte Worker-Klasse das macht. Damit hebst du die Kapselung auf.

    Nein,, ich will keine Kopie in _main_, ich will eine Kopie im Worker-Objekt. Die Beispiel main-Funktion sollte das _unerwartete_ Verhalten demonstrieren. Ich will 'tempString' nachdem ich ihn per Setter an das Worker-Objekt übergeben habe weiter verarbeiten können, ohne das sich der Inhalt des Worker-Objektes verändert. So wie es bei z.B. -setTitle: von NSWindow funktioniert. Ich hebe damit nicht die Kapselung auf. Im Gegenteil, meine Setter-Methode "kapselt besser". :] Ich muss mich in _main_ doch nicht darum Kümmern, was sich im Worker-Objekt tut, wenn ich 'tempString' verändere. Das ist Aufgabe des Worker-Objektes.

    Original von Tom9811
    Machst du eigentlich jedesmal Kopien? Gibt das nicht Ärger mit den Bindings?

    Bei NSString fast immer, ja. Weil Cocoa ist so schlau und macht aus -copy ein -retain, wenn es immutable ist.

    Michael

  • RE: Unklarheiten bei autorelease ???

    ja, das mit dem autorelease ist mein Fehler. Hatte mich verlesen.

    Dennoch: Du willst eine Variable verschieden in MAIN benutzen und verändern und machst deshalb eine Kopie in Worker. Das ist grundfalsch. Die Probleme habe ich unten aufgelistet. Das endet im völligen Chaos.

    Ich hate den Fehler auch nicht nachprogrammiert, sondern beide Verhalten als Code dargestellt. In beiden Varianbten macht er genau das, was man sieht.

    Es gibt freilich Fälle, in denen man Kopien tatsächlich machen möchte. Das ist die Ausnahme.

    Zu den NSStrings: Das ist nicht richtig. NSString hat _keine_ Veränerungsmethode, weshalb er Kopien macht. Das ist ein von Java gestohlenes Konzept. NSString-Objekte sind aber _inhaltlich_ unveränderlich. Sie können ausgetauscht werden. Siehe hierzu mein Beispiel von unten.

    Ein slcehr Setter ist auch ganz bestimmt nicht so von Cocoa gedacht, weil damit KVO, KVC und Cocoa Bindings kaum funktionieren dürften. Ich glaube nicht, dass Apple das will.

    Du hebelst RC völlig aus, weil du alles kopierst. Du brauchst gar keinen RC. Der steht bei dir nie höher als 1. Das ist sicher von Apple nicht gewollt.
    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"?

  • RE: Unklarheiten bei autorelease ???

    Original von Tom9811
    Dennoch: Du willst eine Variable verschieden in MAIN benutzen und verändern und machst deshalb eine Kopie in Worker. Das ist grundfalsch. Die Probleme habe ich unten aufgelistet. Das endet im völligen Chaos.

    Nein, die geschilderten Probleme treten nicht auf. Ich glaube Du hast da auch etwas missverständen. Die von mir vorgeschlagene Art von Setter-Methode wende ich nicht grundsätzlich an, sondern nur bei bestimmten Objekten, wie z.B. NSString.

    Original von Tom9811
    Es gibt freilich Fälle, in denen man Kopien tatsächlich machen möchte. Das ist die Ausnahme.

    Richtig, es ist nicht allgemein gültig. Ich handle da nach folgender Regel, die ich aus dem Buch "Learning Cocoa" habe:

    Copying versus Retaining
    When deciding whether to retain or copy objects, it helps to categorize them as 'value objects' or 'entity objects'. Value objects are objects, such as NSNumbers or NSStrings that encapsulate a discrete, limited set of data. Entity objects, such as NSViews and NSWindows, tend to be larger objects that manage an coordinate subordinate objects
    ...
    In accessor methods that set value-object instance variables, you usually (but not always) want to make your own copy of the object and not share it. ... Send autorelease to the old object and then send copy–not retain–to the new one

    Original von Tom9811
    Ein slcehr Setter ist auch ganz bestimmt nicht so von Cocoa gedacht, weil damit KVO, KVC und Cocoa Bindings kaum funktionieren dürften.

    Funktioniert aber.

    Original von Tom9811
    Du hebelst RC völlig aus, weil du alles kopierst. Du brauchst gar keinen RC. Der steht bei dir nie höher als 1.

    Nein, da hast Du eventuell etwas missverstanden. Ich kopiere nur "value-Objekte" und bei immutable Strings macht Cocoa da sowieso ein retain draus und der RC wird größer als 1!

    Original von Tom9811
    Das ist sicher von Apple nicht gewollt.

    Wie oben gesagt, diese Art von Setter ist nicht auf meinem Mist gewachsen, sondern stammt aus dem Buch, "Learning Cocoa", welches offiziell von Apple als "Recommended Title" bezeichnet wird. An dem Buch hat Apple offensichtlich selbst mitgearbeitet. Alle Programmierbeispiele in dem Buch bekommst Du ja direkt von der Apple Webpage.

    Michael

  • RE: Unklarheiten bei autorelease ???

    In meinem geschildertem Beispiel funktioniert es gewiss nicht.

    Ich schrieb schon, dass es manchmal Situationen gibt, in denen man das möchte. Das ist die Ausnahem. Es funktioniert in der Regel nicht so gewünscht, weil des beobachtete Objekt nicht das gespeicherte ist.

    Wenn du das auf value-Objects beschränkst, ist es in der Tat so, dass ein Copy Sinn macht. Deshalb schreib ich ja auch Ausnahme! Du schriebst "nie so machen".

    Value-Objetcs sind das Gegenteil von KVO, KVC, CB. Sie sind dafür da, Daten unabänderlich von der Außenwelt selbst zu halten. Das ist die Ausnahme, die zudem Speicher kostet. In der Regel will du Beziehungen haben, nicht private Kopien. Wenn jemand einen Namen in einem TableView ändert, soll sich das automatisch fortsetzen. Es soll nicht irgendwo eine private, eigene Kopie stehen bleiben.

    In der Tat läuft das bei einem immutable af das gleiche heraus. Wer garantiert dir, dass es ein immutable ist? Außerdem: Wenn du nur einen retain machen möchtest, warum in Gottes Namen machst du dann nicht einen retain, sondern verschwendest Speicher um das gleiche uneränderliche PObjekt zweimal zu halten? Arbeitet deine Familie in der Speicherindustrie? ;)

    Wenn du dir die Setter in der Aple Doku anschaust, sind sie anders. Nochmal: Es gibt Fälle, da willst du eine "sichere" Kopie. Für die üblichen Accessoren mit KVO, KVC und Cb gibt es Probleme. Außerdem müllst du damit den Speicher zu.
    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"?

  • RE: Unklarheiten bei autorelease ???

    Achja? Ich habe meine Rechner jetzt nicht hier. Ich erinnere mich aber dann doch anders.

    Aber mal eine schnelle google Suche:
    stepwise.com/Articles/Technical/2001-03-11.01.html
    macdevcenter.com/pub/a/mac/excerpt/Cocoa_ch04

    Wenn man so vorgeht wie Michael, dann braucht man gar keinen RC. Der wird nämlich nie größer als 1. Das kann wohl nciht der Sinn sein, oder?
    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"?

  • RE: Unklarheiten bei autorelease ???

    Wie kommst du auf die absurde Behauptung?
    GraphicBindigs/GraphicsArrayCotnroller:- (void)setFilterColor:(NSColor *)aFilterColor
    BezierPathLab/BezierView/setLineColor:
    BezierPathLab/BezierView/setFillColor:
    BezierPathLab/BezierView/setBackgroundColor:
    ClipBoardViewer/LazyDataTextStorage/setAttributes:
    ClipBoardViewer/LazyDataTextStorage/setString:
    ClockControl/ApppointmentData/setTime:
    ClockControl/ApppointmentData/setInfo:

    Hier habe ich dann aufgehört.

    Ich kannn eher das Gegenteil erkennen.
    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"?