2016-02-23 10 views
5

Nhìn vào vulkan.h tôi thấy điều này:Tại sao trong các đối tượng không thể gửi đi vulkan.h luôn được đánh máy là 64 bit?

#if defined(__LP64__) || defined(_WIN64) || defined(__x86_64__) || ..... 
    #define VK_DEFINE_NON_DISPATCHABLE_HANDLE(object) typedef struct object##_T *object; 
#else 
    #define VK_DEFINE_NON_DISPATCHABLE_HANDLE(object) typedef uint64_t object; 
#endif 

Có ai có ý tưởng tại sao 64bits? Đối với tôi nó có vẻ hợp lý hơn để luôn luôn sử dụng trường hợp đầu tiên của ifdef

+1

"Luôn luôn"? - Theo mã được hiển thị, họ không phải. Nhưng con trỏ có kích thước nào trên nền tảng không phải là 64 bit? Và nó có kích thước nào trên nền tảng được sử dụng cho những trường hợp đầu tiên? – Olaf

+2

Câu hỏi của tôi dựa trên giả định rằng nền tảng 64bit có con trỏ 64bit – hiddenbit

Trả lời

5

Trong spec it explicitly says rằng tay cầm phi Dispatchable phải 64 bit:

loại xử lý

Non-Dispatchable là một 64-bit số nguyên loại có ý nghĩa phụ thuộc vào việc triển khai thực hiện và có thể mã hóa thông tin đối tượng trực tiếp trong xử lý thay vì trỏ đến cấu trúc phần mềm. Các đối tượng thuộc loại không thể gửi đi có thể không có giá trị xử lý duy nhất trong một loại hoặc trên các loại. Nếu giá trị xử lý không phải là duy nhất, thì phá hủy một tay cầm như vậy không được xử lý các loại khác nhau trở thành không hợp lệ và không được xử lý giống nhau của cùng loại trở nên không hợp lệ nếu giá trị xử lý đó đã được tạo thêm lần hơn là nó đã bị phá hủy.

+0

Cảm ơn bạn đã tham khảo! Nó đơn giản và rõ ràng hơn tôi nghĩ. – hiddenbit

+2

Nếu đó là trường hợp, thì tại sao các xử lý được định nghĩa là con trỏ trên kiến ​​trúc 64 bit, chứ không phải là uint64_t? Sau khi đọc đoạn đó, có vẻ như tôi hợp lý hơn để luôn sử dụng phần thứ hai của #ifdef. –

+0

@AndrewWilliamson có lẽ vì C và C++ không có typedefs mạnh nên chúng sử dụng con trỏ để giúp loại an toàn. –

Các vấn đề liên quan