Đàn áp " '...' bị phản đối" khi sử dụng respondsToSelector

Question

tôi đang ủng hộ 10.4+ bằng cách chọn API nhiều nhất hiện nay trong thời gian chạy:

if ([fileManager respondsToSelector:@selector(removeItemAtPath:error:)]) 
    [fileManager removeItemAtPath:downloadDir error:NULL]; 
else 
    [fileManager removeFileAtPath:downloadDir handler:nil]; 

Trong trường hợp này, 10.5 và lên sẽ sử dụng removeItemAtPath:error: và 10.4 sẽ sử dụng removeFileAtPath:handler:. Tuyệt vời, nhưng tôi vẫn nhận được cảnh báo trình biên dịch cho các phương pháp cũ:

warning: 'removeFileAtPath:handler:' is deprecated [-Wdeprecated-declarations] 

Có một cú pháp của if([… respondsToSelector:@selector(…)]){ … } else { … } rằng gợi ý trình biên dịch (Clang) để không cảnh báo trên dòng đó?

Nếu không, có cách nào gắn thẻ dòng đó bị bỏ qua cho -Wdeprecated-declarations không?

---

Sau khi xem một số câu trả lời, hãy để tôi làm rõ rằng làm cho trình biên dịch hiểu rằng những gì tôi đang làm không phải là giải pháp hợp lệ.

Answer 1

tôi thấy an example trong tay người dùng của Clang trình biên dịch cho phép tôi bỏ qua những cảnh báo:

if ([fileManager respondsToSelector:@selector(removeItemAtPath:error:)]) { 
    [fileManager removeItemAtPath:downloadDir error:NULL]; 
} else { 
#pragma clang diagnostic push 
#pragma clang diagnostic ignored "-Wdeprecated-declarations" 
    [fileManager removeFileAtPath:downloadDir handler:nil]; 
#pragma clang diagnostic pop 
} 

Answer 2

Bạn có thể khai báo một tập tin riêng biệt mà được thiết kế để gọi các phương pháp phản đối và thiết lập các cờ cho mỗi tập tin biên dịch trong Xcode để bỏ qua -Wdeprecated-declarations. Sau đó, bạn có thể xác định hàm giả trong tệp đó để gọi các phương thức không được chấp nhận và do đó tránh các cảnh báo trong tệp nguồn thực của bạn.

Answer 3

Tôi không chắc liệu clang có đủ thông minh để nắm bắt điều này hay không, nhưng nếu không, bạn có thể thử sử dụng performSelector:withObject:withObject: hoặc xây dựng và gọi một đối tượng NSInvocation.

Answer 4

Bạn chỉ có thể đúc fileManager một id-ids có thể tham khảo bất kỳ đối tượng Objective-C, do đó trình biên dịch là không được phép kiểm tra các phương pháp được gọi là trên một:

[(id)fileManager removeItemAtPath:downloadDir error:NULL]; 

shouldn 't tăng bất kỳ cảnh báo hoặc lỗi nào.

Tất nhiên, điều này làm tăng các vấn đề khác - cụ thể là bạn mất tất cả kiểm tra thời gian biên dịch cho các phương thức được gọi là id. Vì vậy, nếu bạn viết sai chính tả tên phương thức, v.v., nó sẽ không bị bắt cho đến khi dòng mã được thực thi.

Answer 5

Nếu bạn xem xét bất kỳ hình thức "gây nhầm lẫn" trình biên dịch là một giải pháp không hợp lệ, có thể bạn sẽ phải sống với cảnh báo. (Trong cuốn sách của tôi, nếu bạn yêu cầu làm thế nào để loại bỏ một cảnh báo, nó không khôn ngoan để nhìn một con ngựa món quà trong miệng và nói điều gì đó không hợp lệ chỉ vì nó không giống như bạn mong đợi.)

câu trả lời mà làm việc tại thời gian chạy liên quan đến mặt nạ hoạt động đó đang xảy ra với công văn năng động, do đó trình biên dịch không phàn nàn về các cuộc gọi không được chấp nhận. Nếu bạn không thích phương pháp đó, bạn có thể tắt "Cảnh báo về các chức năng không được chấp nhận" trong dự án Xcode hoặc cài đặt đích của bạn, nhưng đó thường là một ý tưởng tồi. Bạn muốn biết về các API không dùng nữa, nhưng trong trường hợp này bạn muốn sử dụng nó mà không cần cảnh báo. Có những cách dễ dàng và khó khăn để làm điều này, và tỷ lệ cược là bạn sẽ xem xét tất cả chúng "không hợp lệ" trong một số hình thức, nhưng điều đó không ngăn cản chúng được hiệu quả, thậm chí chính xác.;-)

Một cách có thể để tránh những lời cảnh báo nhưng vẫn chọn trong thời gian chạy là sử dụng objc_msgSend() trực tiếp:

objc_msgSend(fileManager, @selector(removeFileAtPath:error:), downloadDir, nil]; 

This is what the Objective-C runtime does under the covers anyway, và cần đạt được kết quả bạn muốn với tối thiểu là phiền phức. Bạn thậm chí có thể rời khỏi dòng ban đầu đã nhận xét ở trên nó cho rõ ràng. Tôi biết tài liệu nói rằng, "Trình biên dịch tạo ra các cuộc gọi đến chức năng nhắn tin. Bạn không bao giờ nên gọi nó trực tiếp trong mã bạn viết." Một mình bạn phải quyết định khi nào thì không thể bẻ cong các quy tắc.