Collectives™ on Stack Overflow

Find centralized, trusted content and collaborate around the technologies you use most.

Teams

Q&A for work

Connect and share knowledge within a single location that is structured and easy to search.

I'm supporting 10.4+ by picking the most-current API at runtime:

if ([fileManager respondsToSelector:@selector(removeItemAtPath:error:)])
    [fileManager removeItemAtPath:downloadDir error:NULL];
    [fileManager removeFileAtPath:downloadDir handler:nil];
In this case, 10.5 and up will use removeItemAtPath:error: and 10.4 will use removeFileAtPath:handler:. Great, but I still get compiler warnings for the old methods:
warning: 'removeFileAtPath:handler:' is deprecated [-Wdeprecated-declarations]
Is there a syntax of if([… respondsToSelector:@selector(…)]){ … } else { … } that hints the compiler (Clang) to not warn on that line?
If not, is there a way to tag that line to be ignored for -Wdeprecated-declarations?
After seeing some of the answers, let me clarify that confusing the compiler into not knowing what I'm doing is not a valid solution.
I found an example in the Clang Compiler User's Manual that lets me ignore the warning:
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
                Can you just wrap the call in #pragma clang diagnostic ignored "-Wdeprecated-declarations" and then #pragma clang diagnostic warning "-Wdeprecated-declarations" if Clang on OS X doesn't support push?
– Wevah
                Dec 14, 2009 at 22:24
                @sidnicious can you tell me how to know the specific name of the warning. I mean, it shows the warning "<method name> is depricated" but we using "-Wdeprecated-declarations". How to find atual name we need to use in clang diagnostics
– Johnykutty
                Sep 16, 2013 at 16:16
You could declare a separate file that is designated for calling deprecated methods and set the per-file compiler flags in Xcode to ignore -Wdeprecated-declarations. You can then define a dummy function in that file to call the deprecated methods, and thereby avoid the warnings in your real source files.
                Good idea, especially since it gets all the deprecated API calls in one place. I moved the compatibility code into a separate file, adding -compatibility* methods to categories on the classes in question (for example, -[NSFileManager compatibleRemoveItemAtPath:]).
– s4y
                Dec 15, 2009 at 22:16
                performSelector: and kin are the correct solution to calling Objective-C methods at runtime when you're not certain whether they exist.
– cdespinosa
                Dec 15, 2009 at 4:19
You could just cast fileManager to an id — ids are able to refer to any Objective-C object, so the compiler isn't supposed to check methods which are called on one:
[(id)fileManager removeItemAtPath:downloadDir error:NULL];
shouldn't raise any warnings or errors.
Of course, this raises other problems — namely, you lose all compile-time checking for methods called on the id. So if you misspell you method name, etc, it wont be caught until that line of code is executed.
                Same solution but a little bit less permissive can be found here: vgable.com/blog/2009/06/15/ignoring-just-one-deprecated-warning
– MonsieurDart
                Nov 28, 2010 at 21:07
If you consider any form of "confusing" the compiler to be an invalid solution, you're probably going to have to live with the warning.  (In my book, if you asking how to get rid of a warning, it's unwise to look a gift horse in the mouth and say something is invalid just because it doesn't look like you'd expect.)
The answers that work at runtime involve masking the operation that's happening with dynamic dispatch so the compiler doesn't complain about the deprecated call. If you don't like that approach, you can turn off "Warn About Deprecated Functions" in your Xcode project or target settings, but that's generally a bad idea. You want to know about deprecated APIs, but in this case you want to use it without warning. There are easy and hard ways to do this, and odds are you'd consider all of them "invalid" in some form, but that doesn't prevent them from being effective, even correct. ;-)
One possible way to avoid the warnings yet still select at runtime is to use objc_msgSend() directly:
objc_msgSend(fileManager, @selector(removeFileAtPath:error:), downloadDir, nil];
This is what the Objective-C runtime does under the covers anyway, and should accomplish the result you want with a minimum of fuss. You can even leave the original line commented above it for clarity. I know the documentation says, "The compiler generates calls to the messaging function. You should never call it directly in the code you write." You alone have to decide when it's okay to bend the rules.
                Code should say what it means. If it doesn't, then the API, the language, or the programmer is broken. If the compiler is warning when the programmer is confident that his code is correct, then either the compiler needs to learn about that situation and ignore it automatically, or it needs to support a syntax that lets the it ignore that particular warning on that line (like the syntax I posted that doesn't work in the Clang that ships with Xcode). Anything else is a hack.
– s4y
                Dec 15, 2009 at 20:55
                I applaud your idealism, but sometimes you have to compromise. The code I've posted, and that others have as well, does say what it means. I believe you mean that the compiler should be able to divine your intent based purely on code, without jumping through hoops. That's nice and all, but how do you propose the compiler should know that you'll only call a given method on runtime where it's not deprecated? Without additional semantic information, it really can't. Syntax that can communicate such meaning would be fantastic, but until it exists, calling everything else a hack is unproductive.
– Quinn Taylor
                Dec 15, 2009 at 22:08
                Sometimes writing code that isn't crystal clear to the casual observer is unavoidable. This is a perfect time to add a clarifying comment if necessary. Using either performSelector:withObject:withObject: or objc_msgSend() are minimally disruptive approaches that still communicate your meaning and avoid the warning. Java has annotations to suppress warnings, but C does not. Bummer, but life goes on. I'm not defending the current state of things as how it ought to be, just suggesting that if you're going to actually use the language, it's more effective to embrace its quirks than be elitist.
– Quinn Taylor
                Dec 15, 2009 at 22:12
                To answer your question: the compiler already has a list of deprecated methods, why not give it a list of alternative methods as well? Then, if it sees a deprecated call, it could look to see if it is inside the else branch of a conditional that tests [<OBJECT> respondsToSelector:@selector(<ALTERNATIVE>))].
– s4y
                Dec 15, 2009 at 22:31
                I understand your viewpoint, yet I think these answers are about as good as you can expect for now. The deprecated/alternative method approach is an interesting idea, but one that would require fundamental changes to the syntax and semantics of marking code as deprecated. I prefer the safety of compiler checking whenever possible, and avoid casting as id just to avoid warnings. However, spurious warnings tend to distract me more than an occasional hack, particularly when I have unit tests in place to verify that the code work correctly. :-) FWIW, I agree about per-line warning suppression.
– Quinn Taylor
                Dec 15, 2009 at 23:12
        
Thanks for contributing an answer to Stack Overflow!
Please be sure to answer the question. Provide details and share your research!
But avoid …
Asking for help, clarification, or responding to other answers.
Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.