Jetzt gibt es ein iPhone mit 64-Bit-Architektur. long wird zu 64 bit (während int 32-bit bleibt), und überall, wo NSInteger benutzt wurde, ist jetzt long und also 64-bit nicht 32. Und twitter hat ziemlich viele Leute, die sagen: "Ich bin froh Ich habe NSInteger überall nicht verwendet ".
Wenn Sie einen Wert speichern müssen, der 32 Bits nicht überschreitet (zum Beispiel in einer Schleife, die nur 25-mal eine Schleife ausführt), warum sollte eine lange verwendet werden, weil die 32 (mindestens) oberen Bits sein werden leer.
Wenn das Programm mit 32-Bit-Integer gearbeitet hat, welchen Nutzen hat dann die Verwendung von 64-Bit für Integer, wenn es mehr Speicher verbraucht?
Es gibt auch Situationen, in denen die Verwendung einer 64-Bit-Ganzzahl ein anderes Ergebnis ergibt als die Verwendung einer 32-Bit-Ganzzahl. Wenn Sie also NSInteger verwenden, kann etwas auf einem iPhone 5S funktionieren, aber nicht auf einem älteren Gerät. Wenn hingegen int oder long explizit verwendet wird, ist das Ergebnis auf jedem Gerät gleich.
Wenn Sie einen Wert speichern müssen, der 32 Bit nicht überschreitet ... warum sollte ein Long verwendet werden?
Wenn Sie wirklich diese Garantie geben können, gibt es absolut keinen Grund, einen 64-Bit-Typ über einen 32-Bit-Typ zu bewerten. Für einfache Operationen wie gebundene Schleifen, Zähler und allgemeine Arithmetik genügen 32-Bit-Ganzzahlen. Aber für komplexere Operationen, insbesondere solche, die für Hochleistungsanwendungen erforderlich sind - wie beispielsweise solche, die Audio- oder Bildverarbeitung durchführen - ist die Zunahme der Datenmenge, die der Prozessor in 64-Bit-Modi verarbeiten kann, von Bedeutung.
Wenn das Programm mit 32-Bit-Integer gearbeitet hat, welchen Nutzen hat dann die Verwendung von 64-Bit für Integer, wenn es mehr Speicher verbraucht?
Sie machen die Verwendung von mehr Speicher als eine schlechte Sache. Durch die Verdopplung der Größe einiger Datentypen können sie an mehr Speicherorte adressiert werden, und je mehr Speicher adressiert werden kann, desto weniger Zeit benötigt das Betriebssystem zum Laden von Code. Darüber hinaus entspricht das Doppelte der Menge von Spuren für Daten in einem Prozessorbus einer Größenordnung von mehr Werten, die in einem einzigen Durchgang verarbeitet werden können, und die Zunahme der Registergröße bedeutet, dass eine Größenordnung um mehr Daten herumgehalten werden kann ein Register. Dies entspricht, vereinfacht gesagt, einer fast automatischen Verdopplung der Geschwindigkeit der meisten Anwendungen.
Es gibt auch Situationen, in denen die Verwendung einer 64-Bit-Ganzzahl ein anderes Ergebnis ergibt als die Verwendung einer 32-Bit-Ganzzahl? ...
Ja, aber nicht so, wie du denkst. 32-Bit-Datentypen und -Operationen sowie 64-Bit-Operationen (meist in Software simuliert oder durch spezielle Hardware oder Opcodes in 32-Bit-Hosts) sind hinsichtlich ihrer Größe "relativ stabil". Sie können nicht so viele Garantien für eine 64-Bit-Architektur geben, da verschiedene Compiler verschiedene Versionen von 64-Bit-Datentypen implementieren (siehe LP64, SILP64 und LLP64 ). Praktisch bedeutet dies, einen 64-Bit-Typ auf einen 32-Bit-Typ zu übertragen - etwa einen Zeiger auf einen Int -, was garantiert zu Informationsverlust führt, aber zwischen zwei Datentypen, die garantiert 64 Bit sind - ein Pointer und ein Long auf LP64 - ist akzeptabel. ARM wird normalerweise mit LP64 kompiliert (alle Eingänge sind 32-Bit, alle langen 64-Bit). Auch hier sollten die meisten Entwickler nicht von der Umstellung betroffen sein. Wenn Sie jedoch mit beliebig großen Zahlen arbeiten, die Sie in Ganzzahlen speichern möchten, wird die Genauigkeit zum Problem.
Aus diesem Grund würde ich empfehlen, NSUInteger und NSInteger in öffentlichen Schnittstellen und APIs zu verwenden, wo es keine inhärenten Begrenzungsüberprüfungen oder Überlaufwachen gibt. Ein TableView fordert beispielsweise eine NSUInteger-Datenmenge an, nicht weil es sich um 32- und 64-Bit-Datenstrukturen sorgt, sondern weil es keine Garantien für die Architektur geben kann, auf der es kompiliert wird. Apples Versuch, architekturunabhängige Datentypen zu erstellen, ist eigentlich ein bisschen Luxus, wenn man bedenkt, wie wenig Arbeit man dafür braucht, damit der Code in beiden Architekturen kompiliert und "einfach funktioniert".
Der interne Speicher für NSInteger kann einer von vielen verschiedenen Backing-Typen sein, weshalb Sie ihn überall verwenden können und sich nicht darum kümmern müssen. Das ist der Sinn des Ganzen.
Apple kümmert sich um Abwärtskompatibilität, wenn Ihre App auf einer 32- oder 64-Bit-Engine ausgeführt wird und Ihre Variable im Hintergrund mit dem Makro __LP64__ in den richtigen Datentyp konvertiert.
Tags und Links objective-c 64bit