Toán tử xóa tự kiểm tra nếu con trỏ là nullptr. Có bất kỳ chi phí hiệu năng nào khi gọi xóa trên nullptr mà không tự kiểm tra nó không?Xóa nullptr - chi phí hiệu năng?
delete ptr;
hoặc
if (ptr != nullptr) delete ptr;
Mà các thực thi trên nhanh hơn nếu ptr là nullptr?
Như thường lệ, nó phụ thuộc vào trình biên dịch.
Tôi sử dụng MSVC, trong đó biên dịch cả hai dòng này thành chính xác cùng một mã.
Quy tắc nói rằng nếu con trỏ là null, quá trình xóa sẽ không có hiệu lực. Vì vậy, nếu bạn không kiểm tra xem, trình biên dịch có anyway.
Đây chắc chắn là trường hợp tối ưu hóa quá mức. Trên bất kỳ bộ vi xử lý hiện đại, sự khác biệt là một vài nano giây.
Bằng cách thực hiện kiểm tra, mã sẽ tránh được chi phí cuộc gọi (để xóa thường trình thư viện). Trong 99% các trường hợp, sự phức tạp thêm chút của mã nguồn (niềng răng, viết lỗi có khả năng gõ !=, v.v.) là một vấn đề lớn hơn thời gian thực hiện thêm.
Séc phải nằm trong mã được tạo, trước khi gọi đến thư viện ':: operator delete()', vì trình biên dịch không được phép gọi hàm hủy, hoặc, nếu con trỏ là 'null'. –
Không, không có bất kỳ phí nào khi bạn không kiểm tra xem ptr có phải là nullptr hay không.
Nếu bạn thực hiện kiểm tra thủ công, kiểm tra tương tự được thực hiện hai lần, mặc dù điều này là không đáng kể, so với chi phí của cuộc gọi hệ thống, bạn có thể mong đợi nếu ptr không phải là rỗng.
Ngoài ra, nếu bạn đã sử dụng C++ 11, có thể xem xét không sử dụng xóa ở tất cả và sử dụng con trỏ thông minh để thay thế? –
C++ 11 là không cần thiết - Boost đã có con trỏ thông minh tốt trong nhiều năm. : -] – ildjarn
Tất nhiên! Nhưng khi họ nằm ngay dưới tay bạn, bạn không còn lý do gì để không sử dụng chúng trong hầu hết các trường hợp tiêu chuẩn :) –
Điều nào ở trên thực hiện nhanh hơn nếu ptr là nullptr?
Giả sử kiểm tra của bạn không được tối ưu hóa, công cụ đầu tiên sẽ nhanh hơn. Nếu nó được tối ưu hóa đi, không phải sẽ nhanh hơn. Để nó vào trình biên dịch.
Sau đó là dư thừa, do đó, sự khác biệt tốc độ tiềm năng sang một bên, nó tồi tệ hơn. – ildjarn