2012-05-09 68 views
7

Tôi đọc ở đâu đó sử dụng BOOL (typedef int) là tốt hơn so với sử dụng loại bool tiêu chuẩn C++ vì kích thước của BOOL là 4 byte (nghĩa là bội số của 4) và nó tiết kiệm các hoạt động căn chỉnh của các biến vào sổ đăng ký hoặc một số thứ dọc theo các đường đó ...C++ BOOL (typedef int) vs bool cho hiệu suất

Có sự thật nào về điều này không? Tôi tưởng tượng rằng trình biên dịch sẽ pad các khung stack để giữ cho sự sắp xếp của nhiều của 4s ngay cả khi bạn sử dụng bool (1 byte)?

Tôi không phải là chuyên gia về các hoạt động cơ bản của các sắp xếp, sổ đăng ký, v.v. vì vậy tôi xin lỗi trước nếu tôi đã hoàn toàn sai. Tôi hy vọng sẽ được sửa chữa. :)

Chúc mừng!

+6

Nếu 'bool' nhanh hơn 4 byte, trình biên dịch sẽ tạo 4 byte. Nó phụ thuộc vào kịch bản. Vì vậy, không, 'BOOL' không mang lại lợi ích hiệu suất. – tenfour

+0

Đây là loại điều bạn chỉ có thể tìm hiểu thông qua lược tả, nhưng bạn có muốn một bool có thể có giá trị khác 0,1 không? Ngay cả giá trị âm? – juanchopanza

+0

Điều này sẽ không tạo ra bất kỳ sự khác biệt nào. Các trình biên dịch các giá trị để đảm bảo rằng chúng được liên kết đúng cách. Sử dụng loại phù hợp nhất. Nếu đó là một giá trị Boolean, làm cho nó là một 'bool', không phải là một' int' (hoặc một số 'typedef' của nó). –

Trả lời

7

Trước hết, sizeof(bool) không nhất thiết phải là 1. Nó là implementation-defined, cho phép người viết trình biên dịch tự do lựa chọn kích thước phù hợp cho nền tảng đích.

Ngoài ra, sizeof(int) không nhất thiết phải là 4.

Có nhiều vấn đề có thể ảnh hưởng đến hiệu suất:

  • liên kết;
  • băng thông bộ nhớ;
  • Khả năng của CPU để tải các giá trị có hiệu quả hẹp hơn từ máy.

Điều gì sẽ xảy ra nếu bạn có thể thiết lập bất kỳ sự khác biệt nào tạo thành một đoạn mã cụ thể bằng cách lược tả đoạn mã đó.

+0

Và trình biên dịch có lẽ sẽ thích nghi với kích thước của một 'bool' để phản ánh những vấn đề này. –

+0

Nói chung mặc dù; Vì lợi ích của ví dụ nói rằng bool là 1 byte và nói rằng int là 4 byte. Giả sử bạn có cấu trúc {bool x; int y}; Liệu x gây ra y để được bỏ lỡ phù hợp bởi vì nó là kích thước không phải là bội số của 4? Hay trình biên dịch có đệm các địa chỉ để y được căn chỉnh không? –

+1

@KarlHansson: Vùng đệm được triển khai cụ thể. Các triển khai mà tôi quen thuộc sẽ chèn đệm sau 'x' để' y' được căn chỉnh phù hợp. – NPE

2

Kích thước đảm bảo duy nhất mà bạn có thể nhận được trong C++ là với char, unsigned char, và signed char2), đó là luôn luôn chính xác một byte và định nghĩa cho mỗi nền tảng. 0)1)


0) Mặc dù một byte không có một kích thước xác định. sizeof(char) luôn là 1 byte, nhưng có thể là 40 bit nhị phân trên thực tế

1) Vâng, có uint32_t và bạn bè, nhưng không, định nghĩa của họ là không bắt buộc đối với việc triển khai thực tế C++. Sử dụng chúng, nhưng bạn có thể nhận được biên dịch lỗi thời gian nếu họ không có sẵn (biên dịch lỗi thời gian luôn tốt)

2) char, unsigned char, và signed char nhiều loại khác nhau và nó không được định nghĩa cho dù charsigned hoặc không phải. Hãy ghi nhớ điều này khi quá tải các chức năng và viết mẫu.

0

Có ba thông lệ thực hiện theo định hướng thường được chấp nhận trong trường hợp các phép toán luận:

  1. Trong if-báo cáo để kiểm tra những biểu hiện vấn đề và người ta cần phải cẩn thận về họ.
  2. Nếu kiểm tra biểu thức boolean gây ra rất nhiều chi tiết sai lệch, thì nên (nếu có thể) được thay thế bằng một chút hack twiddling.
  3. Vì boolean là kiểu dữ liệu nhỏ nhất nên các biến boolean phải được khai báo cuối cùng trong các cấu trúc và các lớp, do đó đệm không thêm các lỗ đáng chú ý trong bố trí bộ nhớ cấu trúc.

Tôi chưa bao giờ nghe nói về bất kỳ lợi ích hiệu suất nào từ việc thay thế một số nguyên boolean bằng dấu (unsigned?).

+0

# 3 không nhất thiết phải đúng. Trong một kịch bản mà đã có một khoảng trống trong cấu trúc (do căn chỉnh/tự động đệm), bạn có thể "lấp đầy" khoảng trống cho "miễn phí" bằng cách đặt bool ở đó. Cho phép nói cấu trúc này cho đến nay đã có kích thước mà là một bội số hoàn hảo của kích thước dòng bộ nhớ cache, sau đó thêm một bool ở cuối cấu trúc (thay vì lấp đầy khoảng trống) sẽ thực sự gây ra lỗi bộ nhớ cache trong một số trường hợp khi thử để truy cập thành viên bool đó, (trong khi đó sẽ không có cache-miss khác). Bạn nên đánh giá từng cấu trúc một cách độc lập. –

+0

@PreetKukreti bạn nói đúng, tôi nên nói 'các phương pháp được chấp nhận phổ biến mà không đòi hỏi kiến ​​thức về nền tảng cơ bản'. Nếu bạn biết nền tảng mà SW sẽ được thực hiện, thì có, bạn có thể biết căn chỉnh (4 hoặc 8 hoặc ...) và điều chỉnh cho phù hợp - điền vào các lỗ, căn chỉnh với các dòng bộ nhớ cache, v.v. danh sách là các quy tắc chung để xử lý các boolean. –

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