Không có lợi ích thực sự trong cách nó hiện đang được xác định .
Tôi nghi ngờ rằng khi hàm time()
được xác định trước, nó đã sử dụng loại không thể trả về từ một hàm. Việc triển khai C rất sớm không có long int
và không thể trả về cấu trúc từ các hàm. Trên một hệ thống có int int 16 bit, cách duy nhất để biểu diễn một thời gian sẽ là một cấu trúc hoặc như một mảng; 16 bit giá trị của giây là ít hơn một ngày.
triển khai Vì vậy, sớm time()
có thể đã được sử dụng một cái gì đó như thế này (dự đoán):
time_t now;
time(&now); /* sets now.time_high, now.time_low */
hoặc có lẽ:
int now[2];
time_t(now); /* sets now[0], now[1] */
Khi sau C triển khai thêm các số nguyên dài hơn và khả năng quay trở lại cấu trúc theo giá trị, khả năng trả về giá trị time_t
từ chức năng time()
đã được thêm vào, nhưng chức năng cũ được giữ để tránh vi phạm mã hiện tại.
Tôi nghĩ rằng nếu time()
đã được định nghĩa ngày hôm nay, nó sẽ trông như thế này:
time_t time(void);
tôi đã không thể xác nhận rằng việc triển khai cũ của time()
chức năng làm việc theo cách này (thử Googling " thời gian "!), nhưng nó có ý nghĩa cho lịch sử của ngôn ngữ.
Nếu bạn chuyển một con trỏ rỗng tới hàm time()
, nó trả về thời gian hiện tại mà không lưu trữ nó trong một biến; điều này tránh một số hình phạt về hiệu suất:
time_t now = time(NULL);
Nguồn
2012-03-30 15:10:37
Điều đó nghe có vẻ hợp lý. Tôi đã mong đợi các hình phạt hiệu suất để đi theo cách khác. Nó tránh được nếu bạn vượt qua một NULL, nhưng nếu bạn gọi nó với một con trỏ và bỏ qua kết quả trả về, nó vẫn phải xô thời gian vào thanh ghi trả về. Đôi khi tôi quên rằng C gần gấp đôi tuổi như tôi. :) – wjl
* Thỉnh thoảng tôi quên rằng C gần gấp đôi tuổi tôi. * - Cảm ơn đã khiến tôi cảm thấy mình già đi! số 8-)} –