{"id":323,"date":"2009-06-15T21:38:11","date_gmt":"2009-06-16T02:38:11","guid":{"rendered":"http:\/\/vgable.com\/blog\/2009\/06\/15\/ignoring-just-one-deprecated-warning\/"},"modified":"2009-06-17T18:16:22","modified_gmt":"2009-06-17T23:16:22","slug":"ignoring-just-one-deprecated-warning","status":"publish","type":"post","link":"https:\/\/vgable.com\/blog\/2009\/06\/15\/ignoring-just-one-deprecated-warning\/","title":{"rendered":"Ignoring Just One Deprecated Warning"},"content":{"rendered":"

Switching projects over to iPhone OS 3.0 means discovering that functions I’m using are deprecated. Occasionally there isn’t a totally straightforward replacement, and the best thing to do is to file a bug\/TODO\/note for myself<\/em>, and ignore the warning until a later version, when major refactoring will be possible. But bitter experience has taught me to have Xcode treat warnings as errors1<\/sup>, so it’s necessary to trick the compiler into ignoring the warning for things to build.<\/p>\n

-Wno-deprecated<\/code><\/h3>\n

The -Wno-deprecated<\/a><\/code> flag tells GCC to suppress warnings about deprecated code. But adding it to an Xcode project<\/a> means you won’t get useful warnings about other<\/em> depreciated code.<\/p>\n

You could file a bug telling yourself to turn that warning back on after the deprecated functionality has been updated. That should work just fine. But it feels like bad project hygiene to me.<\/p>\n

Casting and Protocols<\/h3>\n

Type casting is a dangerous old-C technique that’s earned<\/em> its infamy. But it’s undeniably fitting to use a deprecated<\/a> language feature to get deprecated code to build. The basic idea is to declare a protocol that includes the method you want to suppress warnings for,<\/p>\n

\n@protocol DeprecatedHack\n- (void) myDeprecatedMethod;\n@end\n<\/pre>\n
then just cast<\/em> your objects so the compiler thinks they implement the protocol,<\/p>\n
\n[foo myDeprecatedMethod]; \/\/warnings\n[(id<DeprecatedHack>>)foo myDeprecatedMethod]; \/\/no warnings\n<\/pre>\n
Although having to declare a protocol is somewhat heavyweight, it leaves a nice artifact in the code<\/em> reminding you to replace deprecated functionality.<\/p>\n
Protocols Not Required<\/h3>\n
Sometimes just casting to id<\/code> is enough. This happens if another object has a non-deprecated method with the same name. <\/p>\n
1<\/sup>For experimental or prototyping projects I let warnings slide. But in the main project I always treat warnings as errors. Ignoring them in production code has never worked — warnings fester and grow on each other.<\/p>\n
Because Objective-C is so dynamic, there are many errors that the compiler can warn you about, but can’t be totally sure<\/em> are errors. For example, methods can be added to a class at runtime, so if you call -someMethodThatDoesNotExistAnywhere<\/code>, the compiler will warn you that something is up, but won’t stop the build, because the necessary code could <\/em>magically appear at runtime. Of course, 99% of the time, it’s me accidentally using count<\/code> when I meant length<\/code>, etc. What I’m really trying to say here is that treating warnings as errors is an even better idea in Objective-C.<\/p>\n
<\/small><\/p>\n","protected":false},"excerpt":{"rendered":"
Switching projects over to iPhone OS 3.0 means discovering that functions I’m using are deprecated. Occasionally there isn’t a totally straightforward replacement, and the best thing to do is to file a bug\/TODO\/note for myself, and ignore the warning until a later version, when major refactoring will be possible. But bitter experience has taught me […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[18,7,203,5,4,10],"tags":[243,76,437,435,422,134],"class_list":["post-323","post","type-post","status-publish","format-standard","hentry","category-bug-bite","category-c","category-iphone","category-objective-c","category-programming","category-tips","tag-compilers","tag-gcc","tag-iphone-os-30","tag-project-management","tag-prometheus-development","tag-xcode"],"_links":{"self":[{"href":"https:\/\/vgable.com\/blog\/wp-json\/wp\/v2\/posts\/323","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/vgable.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/vgable.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/vgable.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/vgable.com\/blog\/wp-json\/wp\/v2\/comments?post=323"}],"version-history":[{"count":0,"href":"https:\/\/vgable.com\/blog\/wp-json\/wp\/v2\/posts\/323\/revisions"}],"wp:attachment":[{"href":"https:\/\/vgable.com\/blog\/wp-json\/wp\/v2\/media?parent=323"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/vgable.com\/blog\/wp-json\/wp\/v2\/categories?post=323"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/vgable.com\/blog\/wp-json\/wp\/v2\/tags?post=323"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}