NSDictionary und redundante Werte - wie kann ich die "faule" Speicherung umgehen?

  • Leider schon. Denn mit "stringWithString" greifst du ja scheinbar wieder nur auf das redundante String Literal zu und bekommst die selben IDs. Bei "stringWithFormat" wird tatsächlich jeweils eine neue ID erzeugt, denn man erzeugt ja auch einen eigenen String. So war zumindest mein Gedankengang - bin ja da blutiger Anfänger. Im Test lässt es sich nachvollziehen.

  • Meine Meinung: Mit dem Ansatz wirst du früher oder später immer wieder auf die Nase fallen. Dictionaries mappen von key nach value, nicht andersrum - egal welche Kunststücke man anstellt. Wenn du die Parents wissen musst, musst du sie dir auf andere Weise merken, z.B. mit Verweisen von Kindern auf Parents, mit eindeutigen IDs oder sonstwie. Aber schlag' dir das Reverse Lookup aus dem Kopf, das kann nur Ärger machen.
    Multigrad - 360°-Produktfotografie für den Mac

  • awado schrieb:

    Leider schon. Denn mit "stringWithString" greifst du ja scheinbar wieder nur auf das redundante String Literal zu und bekommst die selben IDs. Bei "stringWithFormat" wird tatsächlich jeweils eine neue ID erzeugt, denn man erzeugt ja auch einen eigenen String. So war zumindest mein Gedankengang - bin ja da blutiger Anfänger. Im Test lässt es sich nachvollziehen.


    nein eben nicht, wenn du einen MUTABLE-string erstellst bekommst du auch ein neues objekt mit neuer adresse (was du als ID bezeichnest)!

    NSString *s = @"test";
    NSString *s1 = [NSString stringWithString:@"test"];
    NSString *s2 = [NSMutableString stringWithString:@"test"];

    NSLog(@"s: %p", s);
    NSLog(@"s1: %p", s1);
    NSLog(@"s2: %p", s2);

  • gritsch schrieb:

    macmoonshine schrieb:

    stringWithString: ist eine der überflüssigsten Methoden überhaupt. copy und mutableCopy reichen doch vollkommen aus. ;)


    für NSString ist die methode sinnlos, für NSMutableString aber nicht! copy macht ganz was anderes und bei mutablecopy musste noch autorelease hinten dran (jaja, ARC - es gibt aber nicht nur ARC...)

    Ich habe auch nicht behauptet, dass das Eins-Zu-Eins-Ersetzungen sind. Man muss natürlich dabei wissen, was man macht. Ich finde an stringWithString: problematisch, dass sie den Neuling in der Regel auf die falsche Fährte bringt. ;)
    „Meine Komplikation hatte eine Komplikation.“

  • macmoonshine schrieb:

    gritsch schrieb:

    macmoonshine schrieb:

    stringWithString: ist eine der überflüssigsten Methoden überhaupt. copy und mutableCopy reichen doch vollkommen aus. ;)


    für NSString ist die methode sinnlos, für NSMutableString aber nicht! copy macht ganz was anderes und bei mutablecopy musste noch autorelease hinten dran (jaja, ARC - es gibt aber nicht nur ARC...)

    Ich habe auch nicht behauptet, dass das Eins-Zu-Eins-Ersetzungen sind. Man muss natürlich dabei wissen, was man macht. Ich finde an stringWithString: problematisch, dass sie den Neuling in der Regel auf die falsche Fährte bringt. ;)


    warum? sind dann deiner meinung nach auch dataWithData, arrayWithArray, setWithSet etc auch sinnlos?

  • gritsch schrieb:

    macmoonshine schrieb:

    gritsch schrieb:

    macmoonshine schrieb:

    stringWithString: ist eine der überflüssigsten Methoden überhaupt. copy und mutableCopy reichen doch vollkommen aus. ;)


    für NSString ist die methode sinnlos, für NSMutableString aber nicht! copy macht ganz was anderes und bei mutablecopy musste noch autorelease hinten dran (jaja, ARC - es gibt aber nicht nur ARC...)

    Ich habe auch nicht behauptet, dass das Eins-Zu-Eins-Ersetzungen sind. Man muss natürlich dabei wissen, was man macht. Ich finde an stringWithString: problematisch, dass sie den Neuling in der Regel auf die falsche Fährte bringt. ;)


    warum? sind dann deiner meinung nach auch dataWithData, arrayWithArray, setWithSet etc auch sinnlos?

    -klasseWithKlasse: sind zu einer Zeit entstanden, zu der es noch kein ARC gab. Sie sind meinetwegen mehr oder weniger aussagekräftig als -copy und mutableCopy, aber für MRC sind sie bequemer. In Zeiten von ARC haben sie ziemlich viel ihres Charmes verloren.

    Dasselbe gilt übrigens für die übrigen CA und new-Allocatoren. In ARC-Code schreibe ich meistens einen new-Allocator, keinen CA.

    Negm-Awad, Objective-C und Cocoa, Band I, S. 281
    Convenience-Copy
    Für die manuelle Speicherverwaltung existieren wieder Bequemlichkeitsmethoden. Deren Vorteil erhellt sich ebenso wie der Vorteil der Convenience-Allocators gegenüber new-Methoden erst im Kapitel über manuelle Speicherverwaltung. Sie sind bei automatischer Speicherverwaltung auch wieder buchstabengleich.

    Diese Methoden haben den Namen +klasseWithKlasse:, also etwa +instrumentWithInstrument:, wobei das Original als Parameter übergeben wird.

    Bei automatischer Speicherverwaltung bietet sich aber copy an.
    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"?

    Dieser Beitrag wurde bereits 3 mal editiert, zuletzt von Amin Negm-Awad ()

  • gritsch schrieb:

    macmoonshine schrieb:

    gritsch schrieb:

    (und beim umstieg auf ARC muss man das behandeln, stringWithString jedoch nicht)

    Das macht doch das Xcode-Refactoring für Dich. ;)


    komisch dass ich einem programm nicht traue welches dauernd abstürzt und sich teilweise wie software in alpha-version anfühlt...

    warum auf irgendwas vertrauen wenn es genau dafür eine methode gibt?


    Wann hast du dir das letzte mal Xcode 4 angeschaut?^^

  • Amin Negm-Awad schrieb:

    -klasseWithKlasse: sind zu einer Zeit entstanden, zu der es noch kein ARC gab. Sie sind meinetwegen mehr oder weniger aussagekräftig als -copy und mutableCopy, aber für MRC sind sie bequemer. In Zeiten von ARC haben sie ziemlich viel ihres Charmes verloren.

    Dasselbe gilt übrigens für die übrigen CA und new-Allocatoren. In ARC-Code schreibe ich meistens einen new-Allocator, keinen CA.

    Wenn ich mir es recht überlege, brauche ich auch nur sehr selten eine explizite Kopie eines Objekts. Meistens geschieht das Erzeugen einer unveränderlichen Kopie bei mir implizit über Propertys mit der Eigenschaft copy. Bei veränderbaren Kopien erzeuge ich meistens ein leeres Objekt und fülle es mit den gewünschten Daten.
    „Meine Komplikation hatte eine Komplikation.“