Tại sao tai nạn CFRelease (NULL)?

Question

Có một lý do tại sao CFRelease không kiểm tra NULL? Không phải là nó không thể chấp nhận được khi [nil release]; miễn phí (NULL); xóa NULL; tất cả các công việc hoàn toàn tốt đẹp?

Answer 1

Mã nguồn cho CoreFoundation có sẵn công khai. Cụ thể, đối Snow Leopard mã để CFRelease là trong http://www.opensource.apple.com/source/CF/CF-550/CFRuntime.c

Dưới đây là những gì các phần có liên quan trông giống như:

void CFRelease(CFTypeRef cf) { 
    if (NULL == cf) HALT; 
#if DEPLOYMENT_TARGET_MACOSX || DEPLOYMENT_TARGET_EMBEDDED 
    if (CF_IS_COLLECTABLE(cf)) { 
     if (CFTYPE_IS_OBJC(cf)) { 
      // release the GC-visible reference. 
      auto_zone_release(auto_zone(), (void*)cf); 
     } else { 
      // special-case CF objects for better performance. 
      _CFRelease(cf); 
     } 
     return; 
    } 
#endif 
} 

này không trả lời câu hỏi của bạn về động cơ thiết kế, nhưng bạn cũng được hỏi tại sao không CFRelease không kiểm tra NULL. Nó kiểm tra và không thành công khi NULL được chuyển thành tham số.

Niềm tin cá nhân của tôi tương tự như của Quinn- rằng các nhà thiết kế CF cảm thấy đó là lỗi lập trình để chuyển sang NULL.

Answer 2

Tất cả các chức năng này là một phần của các API khác nhau mà theo quy ước khác nhau liên quan đến xử lý NULL:

1. CFRelease là một phần của SDK CoreFoundation C, mà không chấp nhận NULL tài liệu tham khảo như các đối số theo mặc định.
2. [nil release] sử dụng Objective-C (cho phép dereferences của nil)
3. free(NULL) là một phần của thư viện C (libc) mà cho phép NULL luận
4. delete NULL là một phần của ++ thư viện C (libc++) mà cho phép NULL luận

Tôi đoán là CoreFoundation Nhà văn SDK đã quyết định nhất quán hơn với phần còn lại của SDK thay vì có chức năng tương tự trong các SDK khác.

Answer 3

Điểm tốt, dường như nó không có ý nghĩa gì nhiều trong nháy mắt đầu tiên. Tất nhiên, các behavior is properly documented, nhưng nó sẽ được tốt đẹp nếu nó có thể xử lý NULL một cách duyên dáng. Lưu ý rằng CFRetain và CFMakeCollectable (mới trong 10.4, GC được bật trong 10.5) thể hiện cùng một hành vi. Tôi không thuộc về tất cả các động lực để thiết kế nó theo cách đó, nhưng sự nhấn mạnh có lẽ là nhiều hơn về tính nhất quán nội bộ với phần còn lại của khung CoreFoundation.

Rất khó hiểu/không thể biết được lý do tại sao CF được thiết kế theo cách đó trừ khi bạn có thể hỏi một trong các nhà thiết kế. Đoán tốt nhất của tôi là các nhà thiết kế đã quyết định rằng việc chuyển giao NULL cho các chức năng quản lý bộ nhớ là (phải là?) Một lỗi lập trình. Người ta có thể tranh luận rằng việc gây ra sự cố trên NULL là một hành vi "không nhanh" mong muốn, vì các lỗi xảy ra gần như ngay lập tức dễ dàng theo dõi hơn các lỗi mà không làm gì thay vì những gì bạn mong đợi. Cá nhân, tôi thích cách tiếp cận không-không-trên-null, nhưng tôi đoán đó là cuộc sống ...

Do API không thể/sẽ không thay đổi, bạn có thể kiểm tra NULL hoặc khắc phục sự cố trường hợp. Một tùy chọn có thể là định nghĩa một hàm nội tuyến hoặc macro chỉ gọi CFRelease cho các tham chiếu không NULL. Trong bất kỳ trường hợp nào, có thể tốt nhất là phải rõ ràng trong mã của bạn để tránh nhầm lẫn xuống đường.

Answer 4

Bạn có thể xem mã nguồn của CFReleaseProtector để xử lý (hoặc hiểu rõ hơn) vấn đề này.

CFRelease không sụp đổ trên NULL,

http://unsanity.org/archives/haxies/cfrelease_no_mo.php

Bạn có thể giải nén CFReleaseProtector.sit với công cụ unar dòng lệnh (một phần của The Unarchiver, xem danh sách mã tải Google của nó).