NSInteger có thực sự được sử dụng ở mọi nơi không?

Question

Bây giờ có một chiếc iPhone đi kèm với kiến ​​trúc 64-bit. long trở thành 64 bit (trong khi int vẫn 32-bit), và ở khắp mọi nơi NSInteger đã được sử dụng hiện nay là một long và vì vậy 64-bit không 32. Và twitter đã khá một vài người nói "Tôi rất vui vì tôi đã sử dụng ở khắp mọi nơi NSInteger không phải int ".

Nếu bạn cần lưu trữ một giá trị không vượt quá 32 bit (ví dụ trong vòng lặp chỉ lặp lại 25 lần), tại sao nên sử dụng lâu dài, vì 32 bit trên (ít nhất) sẽ trống rỗng.

Nếu chương trình đã làm việc trên các số nguyên 32-bit, sau đó điều gì lợi ích không sử dụng 64-bit cho số nguyên cung cấp, khi nó sử dụng bộ nhớ nhiều hơn?

Cũng sẽ có những tình huống mà sử dụng một số nguyên 64-bit mang lại cho một kết quả khác nhau để sử dụng một số nguyên 32-bit. Vì vậy, nếu bạn sử dụng NSInteger thì một cái gì đó có thể hoạt động trên iPhone 5S nhưng không hoạt động trên một thiết bị cũ, trong khi nếu int hoặc dài được sử dụng một cách rõ ràng thì kết quả sẽ giống nhau trên mọi thiết bị.

Answer 1

Việc lưu trữ nội bộ cho NSInteger thể là một trong nhiều loại ủng hộ khác nhau, đó là lý do tại sao bạn có thể sử dụng nó ở khắp mọi nơi và không cần phải lo lắng về nó, đó là toàn bộ vấn đề của nó.

Answer 2

Nếu bạn cần lưu trữ giá trị không vượt quá 32 bit ... tại sao nên sử dụng lâu dài?

Nếu bạn thực sự có thể đảm bảo điều đó, thì hoàn toàn không có lý do gì để đánh giá loại 64 bit trên một bit 32 bit. Đối với các phép toán đơn giản như vòng lặp, bộ đếm và số học chung, các số nguyên 32 bit đủ. Nhưng đối với các hoạt động phức tạp hơn, đặc biệt là các yêu cầu của các ứng dụng hiệu suất cao - chẳng hạn như các ứng dụng thực hiện xử lý âm thanh hoặc hình ảnh - sự gia tăng số lượng dữ liệu mà bộ xử lý có thể xử lý ở chế độ 64 bit là đáng kể.

Nếu chương trình đã làm việc trên các số nguyên 32 bit, thì lợi ích nào sử dụng 64 bit cho số nguyên cung cấp, khi nào nó sử dụng nhiều bộ nhớ hơn?

Bạn sử dụng nhiều bộ nhớ hơn có vẻ như là điều xấu. Bằng cách tăng gấp đôi kích thước của một số kiểu dữ liệu, chúng có thể được giải quyết tới nhiều vị trí hơn trong bộ nhớ và bộ nhớ càng nhiều càng tốt, thời gian hệ điều hành tải mã càng ít. Bên cạnh đó, có gấp đôi số lượng làn đường cho dữ liệu trong một chiếc xe buýt vi xử lý tương đương với một trật tự của độ lớn hơn giá trị có thể được xử lý trong một đi duy nhất, và sự gia tăng kích thước đăng ký nghĩa theo độ nhiều dữ liệu có thể được giữ xung quanh trong một đăng ký. Điều này tương đương với, trong điều kiện đơn giản nhất, gần như gấp đôi tốc độ của hầu hết các ứng dụng.

Ngoài ra, sẽ có trường hợp khi sử dụng số nguyên 64 bit cho kết quả khác nhau khi sử dụng số nguyên 32 bit? ...

Có, nhưng không theo cách bạn nghĩ. Các kiểu dữ liệu 32 bit và các hoạt động cũng như các hoạt động 64 bit (được mô phỏng nhiều nhất trong phần mềm, hoặc bằng phần cứng hoặc opcodes đặc biệt trong các máy chủ 32 bit) là "tương đối ổn định" về kích thước của chúng. Bạn không thể thực hiện gần như nhiều bảo đảm trên kiến ​​trúc 64 bit vì các trình biên dịch khác nhau thực hiện các phiên bản khác nhau của các kiểu dữ liệu 64 bit (xem LP64, SILP64, and LLP64). Thực tế, điều này có nghĩa đúc một loại 64 bit cho một loại 32-bit - nói một con trỏ đến một int - đảm bảo sẽ dẫn đến mất thông tin, nhưng đúc giữa hai loại dữ liệu mà có bảo đảm là 64 bit - một con trỏ và dài trên LP64 - là chấp nhận được. ARM thường được biên dịch bằng cách sử dụng LP64 (tất cả các int là 32-bit, tất cả các thời gian dài là 64-bit).Một lần nữa, hầu hết các nhà phát triển không nên bị ảnh hưởng bởi switch, nhưng khi bạn bắt đầu xử lý các số lớn tùy ý mà bạn cố gắng lưu trữ trong các số nguyên, thì độ chính xác sẽ trở thành một vấn đề.

Vì lý do đó, tôi khuyên bạn nên sử dụng NSUInteger và NSInteger trong giao diện công cộng và API nơi không có kiểm soát giới hạn cố định hoặc bảo vệ tràn. Ví dụ, một TableView yêu cầu một lượng dữ liệu NSUInteger không phải vì nó lo lắng về cấu trúc dữ liệu 32 và 64 bit, nhưng bởi vì nó có thể không đảm bảo về kiến ​​trúc mà nó được biên dịch. Nỗ lực của Apple để tạo ra các kiểu dữ liệu độc lập về kiến ​​trúc thực sự là một chút xa xỉ, xem xét ít công việc bạn phải làm để lấy mã của bạn để biên dịch và "chỉ làm việc" trong cả hai kiến ​​trúc.

Answer 3

Apple sẽ chăm sóc khả năng tương thích ngược nếu ứng dụng của bạn đang chạy trên động cơ 32 bit hoặc 64 bit và sẽ chuyển biến của bạn sau hậu trường sang loại dữ liệu thích hợp sử dụng macro __LP64__.

#if __LP64__ 
    typedef long NSInteger; 
    typedef unsigned long NSUInteger; 
#else 
    typedef int NSInteger; 
    typedef unsigned int NSUInteger; 
#endif