typedefs thông minh

Question

Tôi luôn sử dụng typedef trong lập trình nhúng để tránh những sai lầm phổ biến:

int8_t-8 bit đã ký số nguyên
int16_t - 16 bit đã ký số nguyên
int32_t-32 bit đã ký số nguyên
uint8_t - 8 bit số không dấu
uint16_t - Số nguyên không dấu 16 bit
uint32_t - Số nguyên không dấu 32 bit

Phương pháp nhúng gần đây (vấn đề 177, chưa có trên trang web) giới thiệu cho tôi ý tưởng hữu ích khi có một số typedef cụ thể về hiệu suất. This standard đề xuất có typedefs cho biết bạn muốn loại nhanh nhất có kích thước tối thiểu.

Ví dụ, người ta có thể khai báo một biến sử dụng int_fast16_t, nhưng nó thực sự sẽ được thực hiện như một int32_t trên một bộ xử lý 32 bit, hoặc int64_t trên một bộ xử lý 64 bit như những người sẽ là loại nhanh nhất trong ít nhất 16 bit trên những nền tảng đó. Trên bộ xử lý 8 bit, nó sẽ là các bit int16_t để đáp ứng yêu cầu kích thước tối thiểu.

Có bao giờ thấy việc sử dụng này trước khi tôi muốn biết

• Bạn đã thấy điều này trong bất kỳ dự án, nhúng hoặc?
• Bất kỳ lý do nào có thể để tránh loại tối ưu hóa này trong typedefs?

Answer 1

Ví dụ, người ta có thể khai báo một biến sử dụng int_fast16_t, nhưng nó thực sự sẽ được thực hiện như một int32_t trên một bộ xử lý 32 bit, hoặc int64_t trên một bộ xử lý 64 bit như những sẽ là nhanh nhất các loại ít nhất là 16 bit trên các nền tảng đó

Đó là những gì int cho, phải không? Bạn có khả năng gặp phải một CPU 8 bit bất kỳ lúc nào, nơi mà không đủ?

Có bao nhiêu kiểu dữ liệu duy nhất mà bạn có thể ghi nhớ?

Có cung cấp nhiều lợi ích bổ sung đáng giá gấp đôi số lượng loại cần xem xét bất cứ khi nào tôi tạo biến số nguyên đơn giản không?

Tôi đang gặp khó khăn trong việc tưởng tượng khả năng có thể được sử dụng nhất quán.

Ai đó sẽ viết một hàm trả về một int16fast_t và sau đó một người khác sẽ đến và lưu biến đó vào một số int16_t.

Điều đó có nghĩa là trong trường hợp ít người biết, các biến thể nhanh thực sự có lợi, nó có thể thay đổi hành vi mã của bạn. Nó thậm chí có thể gây ra lỗi trình biên dịch hoặc cảnh báo.

Answer 2

Kiểm tra stdint.h từ C99.

Answer 3

Tôi thực sự không có nhiều người hâm mộ loại điều này.

Tôi đã thấy điều này được thực hiện nhiều lần (trên thực tế, chúng tôi thậm chí có những kiểu chữ này ở nơi làm việc hiện tại của tôi) ... Đối với hầu hết các phần, tôi nghi ngờ tính hữu dụng thực sự của họ ... Nó làm tôi thay đổi thay đổi vì ... (và có, tôi biết kích thước của một số nội dung được cài sẵn có thể khác nhau) ...

Answer 4

Lý do chính tôi sẽ tránh typedef này là nó cho phép loại nằm cho người dùng. Hãy int16_t vs int_fast16_t. Cả hai loại tên mã hóa kích thước của giá trị vào tên. Đây không phải là một thực tế không phổ biến trong C/C++. Cá nhân tôi sử dụng kích thước cụ thể typedefs để tránh nhầm lẫn cho bản thân mình và những người khác đọc mã của tôi. Phần lớn mã của chúng tôi phải chạy trên cả nền tảng 32 bit và 64 bit và nhiều người không biết các quy tắc định kích thước khác nhau giữa các nền tảng. Các loại như int32_t loại bỏ sự mơ hồ.

Nếu tôi không đọc đoạn thứ 4 của câu hỏi của bạn và thay vào đó chỉ nhìn thấy tên loại, tôi đã giả định đó là một số cách cụ thể về kịch bản có giá trị 16 bit nhanh. Và tôi rõ ràng sẽ sai: (Đối với tôi, nó sẽ vi phạm quy tắc lập trình "không ngạc nhiên" của lập trình.

Có lẽ nếu nó có một động từ phân biệt, chữ cái, từ viết tắt có tên ít có khả năng hơn Có thể int_fast16min_t?

Answer 5

Tôi thường sử dụng size_t, nó sẽ là kích thước địa chỉ nhanh nhất, một truyền thống mà tôi đã chọn trong quá trình nhúng. Và nó không bao giờ gây ra bất kỳ vấn đề hay nhầm lẫn nào trong các vòng kết nối nhúng, nhưng nó thực sự bắt đầu gây ra cho tôi các vấn đề khi tôi bắt đầu làm việc trên các hệ thống 64bit.

Answer 6

Khi tôi đang xem int_fast16_t và tôi không chắc về chiều rộng gốc của CPU mà nó sẽ chạy, nó có thể làm mọi thứ phức tạp, ví dụ như toán tử ~.

int_fast16_t i = 10; 
int_16_t j = 10; 

if (~i != ~j) { 
    // scary !!! 
} 

Bằng cách nào đó, tôi muốn cố ý sử dụng 32 bit hoặc 64 bit dựa trên độ rộng gốc của bộ xử lý.