size_t so với uintptr_t

Tiêu chuẩn C đảm bảo rằng đó size_tlà một loại có thể chứa bất kỳ chỉ số mảng nào. Điều này có nghĩa là, về mặt logic, size_tsẽ có thể giữ bất kỳ loại con trỏ nào. Tôi đã đọc trên một số trang web mà tôi tìm thấy trên Google rằng đây là hợp pháp và / hoặc sẽ luôn hoạt động:

void *v = malloc(10);
size_t s = (size_t) v;

Vì vậy, trong C99, tiêu chuẩn đã giới thiệu các loại intptr_tvà uintptr_tloại, được ký và loại không dấu được đảm bảo để có thể giữ con trỏ:

uintptr_t p = (size_t) v;

Vậy sự khác biệt giữa sử dụng size_tvà là uintptr_tgì? Cả hai đều không dấu và cả hai sẽ có thể giữ bất kỳ loại con trỏ nào, vì vậy chúng có vẻ giống nhau về mặt chức năng. Có bất kỳ lý do thuyết phục thực sự để sử dụng uintptr_t(hoặc tốt hơn, a void *) chứ không phải là size_t, ngoài sự rõ ràng? Trong một cấu trúc mờ, trong đó trường sẽ chỉ được xử lý bởi các hàm bên trong, có lý do gì để không làm điều này không?

Với cùng một mã thông báo, ptrdiff_tđã là một loại được ký có khả năng giữ sự khác biệt của con trỏ và do đó có khả năng giữ hầu hết mọi con trỏ, vậy nó khác với intptr_tnhư thế nào?

Không phải tất cả các loại này về cơ bản đều phục vụ các phiên bản khác nhau của cùng một chức năng sao? Nếu không, tại sao? Tôi không thể làm gì với một trong số họ mà tôi không thể làm với người khác? Nếu vậy, tại sao C99 lại thêm hai loại cơ bản không cần thiết vào ngôn ngữ?

Tôi sẵn sàng bỏ qua các con trỏ hàm, vì chúng không áp dụng cho vấn đề hiện tại, nhưng cứ thoải mái đề cập đến chúng, vì tôi có một nghi ngờ lén lút chúng sẽ là trung tâm của câu trả lời "chính xác".

size_tlà một loại có thể giữ bất kỳ chỉ số mảng. Điều này có nghĩa là, về mặt logic, size_t sẽ có thể giữ bất kỳ loại con trỏ nào

Không cần thiết! Ví dụ, quay trở lại thời của kiến ​​trúc 16 bit được phân đoạn: ví dụ: một mảng có thể bị giới hạn ở một phân đoạn duy nhất (vì vậy 16 bit size_tsẽ làm được) NHƯNG bạn có thể có nhiều phân đoạn (vì vậy intptr_tcần phải chọn loại 32 bit phân khúc cũng như sự bù đắp bên trong nó). Tôi biết những điều này nghe có vẻ kỳ lạ trong những ngày của các kiến ​​trúc không phân chia địa chỉ thống nhất, nhưng tiêu chuẩn PHẢI phục vụ cho nhiều loại hơn so với "những gì bình thường trong năm 2009", bạn biết đấy! -)

Về tuyên bố của bạn:

"Tiêu chuẩn C đảm bảo rằng đó size_tlà một loại có thể chứa bất kỳ chỉ số mảng nào. Điều này có nghĩa là, về mặt logic, size_tsẽ có thể giữ bất kỳ loại con trỏ nào."

Đây thực sự là một ngụy biện (một quan niệm sai lầm do suy luận không chính xác) ^(a) . Bạn có thể nghĩ cái sau theo cái trước nhưng thực tế không phải vậy.

Con trỏ và chỉ mục mảng không giống nhau. Thật hợp lý khi dự tính một triển khai tuân thủ giới hạn các mảng ở 65536 phần tử nhưng cho phép các con trỏ giải quyết bất kỳ giá trị nào trong một không gian địa chỉ 128 bit lớn.

C99 nói rằng giới hạn trên của một size_tbiến được xác định bởi SIZE_MAXvà giá trị này có thể thấp đến 65535 (xem C99 TR3, 7.18.3, không thay đổi trong C11). Con trỏ sẽ khá hạn chế nếu chúng bị giới hạn trong phạm vi này trong các hệ thống hiện đại.

Trong thực tế, có thể bạn sẽ thấy rằng giả định của mình đúng, nhưng đó không phải là vì tiêu chuẩn đảm bảo nó. Bởi vì nó thực sự không đảm bảo nó.

^(a) đây không phải là một hình thức tấn công cá nhân, chỉ nêu lý do tại sao các phát biểu của bạn sai lầm trong bối cảnh suy nghĩ phê phán. Ví dụ: lý do sau đây cũng không hợp lệ:

Tất cả chó con đều dễ thương. Điều này thật dễ thương. Vì vậy, điều này phải là một con chó con.

Sự dễ thương hay nói cách khác của con rối không có ý nghĩa ở đây, tất cả tôi nói rằng hai sự thật không dẫn đến kết luận, bởi vì hai câu đầu tiên cho phép tồn tại những thứ dễ thương không phải là chó con.

Điều này tương tự như tuyên bố đầu tiên của bạn không nhất thiết bắt buộc thứ hai.

Tôi sẽ để tất cả các câu trả lời khác tự đứng ra liên quan đến lý do với các giới hạn phân khúc, kiến ​​trúc kỳ lạ, v.v.

Không phải là sự khác biệt đơn giản trong tên đủ lý do để sử dụng loại thích hợp cho điều đúng?

Nếu bạn đang lưu trữ một kích thước, sử dụng size_t. Nếu bạn đang lưu trữ một con trỏ, sử dụng intptr_t. Một người đọc mã của bạn sẽ biết ngay rằng "aha, đây là kích thước của một thứ gì đó, có thể tính bằng byte" và "oh, đây là một giá trị con trỏ đang được lưu trữ dưới dạng số nguyên, vì một số lý do".

Mặt khác, bạn chỉ có thể sử dụng unsigned long(hoặc, trong những thời điểm hiện đại ở đây unsigned long long) cho mọi thứ. Kích thước không phải là tất cả, tên loại mang ý nghĩa hữu ích vì nó giúp mô tả chương trình.

Có thể kích thước của mảng lớn nhất nhỏ hơn một con trỏ. Hãy nghĩ về kiến ​​trúc được phân đoạn - con trỏ có thể là 32 bit, nhưng một phân đoạn duy nhất có thể chỉ giải quyết được 64KB (ví dụ kiến ​​trúc 8086 chế độ thực cũ).

Mặc dù chúng không còn được sử dụng trong các máy tính để bàn nữa, tiêu chuẩn C được dự định để hỗ trợ các kiến ​​trúc nhỏ, chuyên dụng. Vẫn có những hệ thống nhúng đang được phát triển với CPU 8 hoặc 16 bit chẳng hạn.

Tôi sẽ tưởng tượng (và điều này đúng với tất cả các tên loại) rằng nó truyền đạt tốt hơn ý định của bạn trong mã.

Ví dụ, mặc dù unsigned shortvà wchar_tcó cùng kích thước trên Windows (tôi nghĩ), sử dụng wchar_tthay vì unsigned shortthể hiện ý định rằng bạn sẽ sử dụng nó để lưu trữ một ký tự rộng, thay vì chỉ một số tùy ý.

Nhìn cả về phía trước và phía trước, và nhớ lại rằng các kiến ​​trúc kỳ quặc khác nhau nằm rải rác về cảnh quan, tôi khá chắc chắn rằng họ đang cố gắng bọc tất cả các hệ thống hiện có và cũng cung cấp cho tất cả các hệ thống có thể trong tương lai.

Vì vậy, chắc chắn, cách mọi thứ giải quyết, cho đến nay chúng ta cần không quá nhiều loại.

Nhưng ngay cả trong LP64, một mô hình khá phổ biến, chúng tôi cần size_t và ssize_t cho giao diện gọi hệ thống. Người ta có thể tưởng tượng một hệ thống tương lai hoặc hệ thống tương lai bị ràng buộc nhiều hơn, trong đó việc sử dụng loại 64 bit đầy đủ là tốn kém và họ có thể muốn sử dụng các op I / O lớn hơn 4GB nhưng vẫn có con trỏ 64 bit.

Tôi nghĩ bạn phải tự hỏi: những gì có thể đã được phát triển, những gì có thể đến trong tương lai. (Có lẽ các con trỏ trên toàn hệ thống phân tán 128 bit, nhưng không quá 64 bit trong một cuộc gọi hệ thống, hoặc thậm chí là giới hạn 32 "di sản". :-) Hình ảnh rằng các hệ thống cũ có thể có trình biên dịch C mới .. .

Ngoài ra, hãy nhìn vào những gì tồn tại xung quanh sau đó. Bên cạnh các mô hình bộ nhớ chế độ thực zillion 286, còn các khung hình chính của con trỏ CDC 60 bit / con trỏ 18 bit thì sao? Làm thế nào về loạt Cray? Đừng bận tâm ILP64, LP64, LLP64 bình thường. (Tôi luôn nghĩ microsoft rất tự phụ với LLP64, đáng ra nó phải là P64.) Tôi chắc chắn có thể tưởng tượng một ủy ban đang cố gắng bao gồm tất cả các cơ sở ...

int main(){
  int a[4]={0,1,5,3};
  int a0 = a[0];
  int a1 = *(a+1);
  int a2 = *(2+a);
  int a3 = 3[a];
  return a2;
}

Ngụ ý rằng intptr_t phải luôn thay thế cho size_t và ngược lại.