NSUInteger bei 64bit Problem !?

CodingPhantom · 18. Juli 2014, 22:37

Ich versuche gerade die Array Methode indexOfObject zu benutzen und möchte das Ergebnis in einem int speichern. Nur auf 64Bit wird ja nach einem NSUInteger verlangt...
Wenn ich das Ergebnis dann wie verlangt in einem NSUInteger gespeichert habe und die Zahl weiterverwenden möchte, ist die Zahl aber komplett falsch !!! Dabei kann die Zahl nur zwischen 0 und 3 groß sein... (Da das Array nur 4 Objekte hat)
Wenn ich indexOfObject mit int caste ist die Zahl immer nur -1 !!!

Auf 32bit funktioniert alles prima, aber man muss es ja schließlich anpassen. Hab ich irgendwas vergessen ?

gandhi · 18. Juli 2014, 22:49

Kann es sein, dass dein Objekt gar nicht im Array enthalten ist? Schaut so aus, als ob Du hier "NSNotFound" zurückbekommst.

schönen Gruß

gandhi

CodingPhantom · 18. Juli 2014, 22:52

gandhi schrieb:

Kann es sein, dass dein Objekt gar nicht im Array enthalten ist? Schaut so aus, als ob Du hier "NSNotFound" zurückbekommst.

schönen Gruß

gandhi

Das bezweifle ich, weil unter 32bit doch alles wie geschmiert läuft. Und da ist ja bis auf den NSUInteger alles gleich (es wird eben ein int verwendet).

Michael · 18. Juli 2014, 23:32

CodingPhantom schrieb:

Ich versuche gerade die Array Methode indexOfObject zu benutzen und möchte das Ergebnis in einem int speichern.

Gibt es dafür einen speziellen Grund?

CodingPhantom schrieb:

Nur auf 64Bit wird ja nach einem NSUInteger verlangt...

Die Methode indexOfObject: gibt immer einen NSUInteger zurück. Je nach Zielplattform wird daraus ein 32 oder 64 Bit unsigned int.

CodingPhantom schrieb:

Wenn ich das Ergebnis dann wie verlangt in einem NSUInteger gespeichert habe und die Zahl weiterverwenden möchte, ist die Zahl aber komplett falsch !!! Dabei kann die Zahl nur zwischen 0 und 3 groß sein... (Da das Array nur 4 Objekte hat)

Oder eben NSNotFound.

CodingPhantom schrieb:

Wenn ich indexOfObject mit int caste ist die Zahl immer nur -1 !!!

Dann hat indexOfObject: aber bereits etwas anderes als eine Zahl zwischen 0 und 3 zurück geliefert.

CodingPhantom schrieb:

Auf 32bit funktioniert alles prima, aber man muss es ja schließlich anpassen. Hab ich irgendwas vergessen ?

Zeig mal den problematischen Code oder häng hier besser gleich ein Demoprojekt mit dem Problem an.

gritsch · 18. Juli 2014, 23:52

geh mal in einer schleife alle objekte im array durch und logge das ergebnis von "isEqual" - dann solltest du verstehen warum das resultat NSNotFound ist.

macmoonshine · 19. Juli 2014, 09:45

Haben die Objekte eine überschriebene isEqual:-Methode? Vielleicht ist ja auch der Code nicht 64-safe.

gritsch · 19. Juli 2014, 10:06

macmoonshine schrieb:

Haben die Objekte eine überschriebene isEqual:-Methode? Vielleicht ist ja auch der Code nicht 64-safe.

oder eben KEINE isEqual implementiert wurde und die objekte nur gleich jedoch nicht identisch sind (und nur zweiteres kann die basisimplementation von isEqual prüfen).

macmoonshine · 19. Juli 2014, 11:09

gritsch schrieb:

oder eben KEINE isEqual implementiert wurde und die objekte nur gleich jedoch nicht identisch sind (und nur zweiteres kann die basisimplementation von isEqual prüfen).

Inwiefern würde das dann ein unterschiedliches Verhalten zwischen 32- und 64-Bit-Version erklären?

gritsch · 19. Juli 2014, 11:13

macmoonshine schrieb:

gritsch schrieb:

oder eben KEINE isEqual implementiert wurde und die objekte nur gleich jedoch nicht identisch sind (und nur zweiteres kann die basisimplementation von isEqual prüfen).

Inwiefern würde das dann ein unterschiedliches Verhalten zwischen 32- und 64-Bit-Version erklären?

dass zwei instanzen bei 32 bit eben identisch sind, bei 64 bit nur gleich.
woran das dann liegt kann doch an vielem liegen - zb überlauf (müsste man sehen wie die objekte erstellt werden).

CodingPhantom · 20. Juli 2014, 14:55

gritsch schrieb:

macmoonshine schrieb:

gritsch schrieb:

oder eben KEINE isEqual implementiert wurde und die objekte nur gleich jedoch nicht identisch sind (und nur zweiteres kann die basisimplementation von isEqual prüfen).

Inwiefern würde das dann ein unterschiedliches Verhalten zwischen 32- und 64-Bit-Version erklären?

dass zwei instanzen bei 32 bit eben identisch sind, bei 64 bit nur gleich.
woran das dann liegt kann doch an vielem liegen - zb überlauf (müsste man sehen wie die objekte erstellt werden).

Wie kann das kommen, dass dasselbe Objekt unter 64bit nur gleich ist und nicht mehr so zu handhaben ist wie unter 32bit ?
Also es handelt sich hier um SKSpriteNodes und ich habe bereits unter 64bit versucht, wie von dir geraten, mal durch das Array hindurch zu iterieren und "manuell" mit isEqual zu schauen ob die Objekte identisch sind. Übrigens überprüfe ich nicht den SKSpriteNode an sich, sondern seine Farbe. In dem Array ist also eine Anzahl von Farben und ich überprüfe an welchem Index in dem Array die Farbe des SKSpriteNodes liegt.

macmoonshine · 20. Juli 2014, 15:40

Warum vergleichst Du Farbwerte?

pmau · 20. Juli 2014, 15:42

developer.apple.com/library/ma…c/intfm/NSObject/isEqual:

Wenn man isEqual überschreibt muss man auch immer hash überschreiben.

Wenn man dies nicht tut, wird die Speicheradresse des Objekts benutzt.
Zwei Objekte sind gleich wenn der hash Wert derselbe ist und isEqual ZES liefert.
Genau in der Reihenfolge.

Man kann für alle Objekte hash "1" zurückgeben.
Dann würde jedesmal isEqual aufgerufen.

Bei Dir ist schon bei hash Schluss, da gleiche Objekte denselben hash brauchen.
Umgekehrt müssen 2 Objekte mit demselben hash aber nicht gleich serin.

macmoonshine · 20. Juli 2014, 15:54

pmau schrieb:

Wenn man isEqual überschreibt muss man auch immer hash überschreiben.

Was soll dieser Hinweis nützen? CodingPhantom benutzt doch die isEqual:-Implementierung von UIColor. Die Array-Suche verwendet auch kein Hashing.

Da Apple zu der isEqual:-Methode allerdings nichts in der Doku vermerkt hat, vermute ich, ist es letztendlich die Implementierung von NSObject – also der Vergleich der Speicheradressen. @CodingPhantom: Zwei Farben zu vergleichen ist in der Regel eine ziemlich schlechte Idee.

gritsch · 20. Juli 2014, 16:09

macmoonshine schrieb:

pmau schrieb:

Wenn man isEqual überschreibt muss man auch immer hash überschreiben.

Was soll dieser Hinweis nützen? CodingPhantom benutzt doch die isEqual:-Implementierung von UIColor. Die Array-Suche verwendet auch kein Hashing.

seit wann ist NSArray kein container mehr?

If two objects are equal, they must have the same hash value. This last point is particularly important if you define isEqual: in a subclass and intend to put instances of that subclass into a collection. Make sure you also define hash in your subclass.

gritsch · 20. Juli 2014, 16:10

und zum thema: farben vergleichen ist sehr problematisch (siehe comparing floatingpoint numbers).

pmau · 20. Juli 2014, 16:15

UIColor können nicht verglichen werden wenn sie aus verschiedenen ColorSpaces kommen.

Wenn er denn unbedingt eine Wrapper Klasse schreiben will, könnte er da isEqual und hash benutzen.
Damit indexOfObject funktioniert.

Aber nichts für Ungut. Ihr kommt schon klar, wie ich sehe.

(Hier steht ein Beispiel, nur als Referenz.)
stackoverflow.com/questions/970475/how-to-compare-uicolors

CodingPhantom · 20. Juli 2014, 16:16

gritsch schrieb:

und zum thema: farben vergleichen ist sehr problematisch (siehe comparing floatingpoint numbers).

Dann werde ich wohl darauf ausweichen, den SKSpriteNodes Namen zuzuweisen und sie dann aufgrund von diesem zu vergleichen...
Ich hoffe das begräbt das Problem

CodingPhantom · 20. Juli 2014, 16:18

pmau schrieb:

UIColor können nicht verglichen werden wenn sie aus verschiedenen ColorSpaces kommen.

Wenn er denn unbedingt eine Wrapper Klasse schreiben will, könnte er da isEqual und hash benutzen.
Damit indexOfObject funktioniert.

Aber nichts für Ungut. Ihr kommt schon klar, wie ich sehe.

(Hier steht ein Beispiel, nur als Referenz.)
stackoverflow.com/questions/970475/how-to-compare-uicolors

Die Farben kommen alle aus dem RGB ColorSpace.
Ich habe die benötigten Farben manuell in einem NSMutableArray eingepflegt...

macmoonshine · 20. Juli 2014, 16:19

gritsch schrieb:

seit wann ist NSArray kein container mehr?

Aus der Aussage Die Array-Suche verwendet kein Hashing folgt nicht NSArray ist kein Container. Wie kommst Du auf so etwas?

Hashing macht nur bei der ungeordneten Ablage von Einträgen einen Sinn. Arrays legen hingegen die Einträge nach einem Index geordnet ab. Dafür braucht man keine Hashfunktion.

macmoonshine · 20. Juli 2014, 16:22

CodingPhantom schrieb:

Dann werde ich wohl darauf ausweichen, den SKSpriteNodes Namen zuzuweisen und sie dann aufgrund von diesem zu vergleichen...

Genau dafür sind die Namen ja auch da, und genau aus diesem Grund gibt es so Methoden wie childNodeWithName:.

Ähnliche Themen