Hast Du irgendwelche Optimierungen beim Übersetzen an? Also, ist es ein echter Debug-Build oder nicht? Das kann die Ursache sein, dann hängen die Variablen in irgendwelchen Registern rum und der Debugger hat ein Problem. Oder beim Beispiel oben wird die Zeile "NSString *hi = @"Hallo";" wegoptimiert, weil nie darauf zugegriffen wird.

ciao

gandhi

räumt ARC das weg , weil du die Variable nie benutzt ?
ich hab das hin und wieder das im debugger auch merkwürdige sachen stehen,
was gibt die console aus wenn du im breakpoint "po hi" eingibst ?

etwas OT:

anstatt id solltest du instancetype verwenden (nutzt Apple seit iOS8 auch überall)

dein return in der if kannst du dir sparen und return self nach der if machen anstelle von nil
entweder ist self halt self oder nil

in den Build-Settings.

​räumt ARC das weg , weil du die Variable nie benutzt ?

Das sicherlich auch, die Frage ist nur wann? Ohne weitere Optimierungen durch allerlei schlaue Compiler/und/oder ARC-Runtimes sollte es beim Verlassen des aktuellen Scopes über den Jordan gehen.
Aber das ist keine "weak"-Referenz, d.h. der Pointer wird nicht ausgenullt, wenn das dazugehörige Objekt weggeräumt wird, kann also nicht das "nil" im Debugger erklären. Dazu braucht's noch ein paar Optimierungen

ciao

gandhi

Ich würde sagen "Halo" bzw. "HaloHallo". Der Debugger bzw. die Variablenanzeige ist in Xcode, wie der ganze Rest auch, etwas fehlerbehaftet. Darauf würde ich mich also nicht verlassen. po und NSLog sind momentan die bessere Wahl. Ist wohl zu schwer Objective-C und Swift gleichzeitig in einer IDE zu unterstützen.

der debugger in Xcode 6 ist für die katz.
hierfür zb:

zeigt der debugger in Xcode 6 an, dass s ein NSString ist. In Xcode 5 zeigt er noch korrekterweise an dass s ein NSNumber (bzw dessen _CFNumberIrgendwas ist).

Ja, ARC räumt das bei der Übersetzung weg. Dafür gibt es die Option -exact_lifetime_semantics oder so ähnlich.

kmr schrieb:

Fortrackz schrieb:

Sobald ich NSLog("%@", hi); dahinter schreibe, gibt er "hallo" aus und hat im Debugger plötzlich auch einen Wert. Sonst nicht.

Genau für solche Fälle hat der liebe kmr auf der Macoun 2013 einen Vortrag über Assembler am Beispiel von Dead Store Elimination gehalten. Guck doch einfach in den Vortrag und/oder das Assembly. Dort wirst Du die Lösung finden.

So etwas mehr Zeit:

Glaube ich konkret nicht. DSE würde wohl eher hi wegoptimieren, was er im Debugmode nicht tun sollte und wohl auch nicht tut.

Aber das Problem ist umfassender. So etwas kann auch passieren bei



Hier kann der Call niemals wegoptimiert werden, weil der Compiler nicht weiß, ob es nicht einen Seiteneffekt gibt. Die lokale Variable kann er mit DSE wegoptimieren. Die Referenz bleibt aber bestehen und muss balanciert werden. Also muss ein release her. Stellt sich die Frage, wo das platziert wird. Mit genauer Lebenszeit darf es erst am Ende des Blockes stehen, ohne auch davor.

Ist doch alles kein Problem? Doch ist es: Wenn etwa innerhalb der Methode eine nicht-starke Referenz behalten wird, ist nicht vorhersehbar, wann die auf nil gesetzt wird (weak) oder ein Dangling-Pointer besteht (unsafe unretained).

Heißt übrigens richtig precise lifetime semantics und die Option objc_precise_lifetime

clang.llvm.org/docs/AutomaticR…recise-lifetime-semantics

By default, local variables of automatic storage duration do not have precise lifetime semantics. Such objects are simply strong references which hold values of retainable object pointer type, and these values are still fully subject to the optimizations on values under local control.

Es existiert die Möglichkeit, das auch für die Variable konkret auszuschalten mit dem Attribut objc_precise_lifetime. Kannst du ja mal probieren.

Na, ja, es war kein Problem, weshalb das auch keine Lösung ist. Aber das Wundern ist damit natürlich erklärbar.

kmr schrieb:

Amin Negm-Awad schrieb:

Glaube ich konkret nicht. DSE würde wohl eher hi wegoptimieren, was er im Debugmode nicht tun sollte und wohl auch nicht tut.

DSE war auch nur der Pointer auf den Vortrag und sollte nicht die Lösung sein. Die wichtige Information war die, ins Assembly zu gucken.

Ein Pointer auf einen Macoun-Vortrag sollte ohnehin immer mit einem Thumbs-Up bedient werden.

Allerdings würde ich sagen, dass der Blick in die Doku hier sogar noch besser war. Aber ich sehe ein, dass niemand wirklich Lust hat, sich die ARC-Doku von clang durchzulesen. Auch wenn sie prächtig ist.

Das ist richtig, weil die Speicherverwaltung bei Swift

a) voller Bugs steckt,
b) nicht dokumentiert ist und
c) sich ohnehin von Release zu Release grundlegend ändert.

Aber dafür weiß sie, dass wenn sie ein Instanzobjekt freigibt, von welchem Typen es ist. Keine Ahnung, wozu man das braucht.

+roflmao+

Oder, um dem Ruf eines deutschsprachigen Forums gerecht zu werden:
+MAaüdBr+

Naja, solange die Retains gleich bleiben. +scnr+