Compiler Warnings for Objective-C Developers
1–10 of 31 posts
Re: Compiler Warnings for Objective-C Developers
#2[deleted]
Re: Compiler Warnings for Objective-C Developers
#3I never do -Wall and -Wextra. Why? Because too many of clang's warning switches have names that have little to do with what they actually warn about. One in particular has to do with it finding duplicate selectors in different classes. I can never remember what it's called, but it's very annoying when you need to find it to disable it. Even worse, when you disable that particular flag, it disables a whole bunch of other actually useful warnings as well!
You also DON'T want to do -Wall and -Wextra along with -Werror. Why? Because when a later version of the compiler gets smarter and puts in more warnings, suddenly your (working) code won't compile anymore! That would go over very poorly in a CI system or an open source library! Your "future proofing" has just ensured that sometime down the road (and likely at an inconvenient time), your project is guaranteed to break!
Re: Compiler Warnings for Objective-C Developers
#4I never do -Wall and -Wextra. Why? Because too many of clang's warning switches have names that have little to do with what they actually warn about. One in particular has to do with it finding duplicate selectors in different classes. I can never remember what it's called, but it's very annoying when you need to find it to disable it. Even worse, when you disable that particular flag, it disables a whole bunch of ot…
You can set the warnings to only appear on debug builds. Would that fix the CI issue?
Re: Compiler Warnings for Objective-C Developers
#5The author just retweeted a link to this header file to enable Clang warnings using #pragma's https://github.com/macmade/SeriousCode https://twitter.com/macmade/status/328219581879558144
Re: Compiler Warnings for Objective-C Developers
#6'Treat warnings as errors' is the greatest thing since shirt pockets. I've found that most warnings are really latent errors. I've been using this setting for as long as I've been compiling with GCC/LLVM, going back to gcc 2.x.
Whenever I take over a new project I immediately endeavor to fix all the warnings. The reason is simple: I've spent too much time chasing bugs that were directly related to a specific warning in a sea of them. Once you get a project warning-free it's quite easy to keep it that way.
Regarding the author's specific complaint--unused variables--I find that it's quite simple to comment out the declaration. There's no need to resort to pragmas in this instance.
Re: Compiler Warnings for Objective-C Developers
#7I never do -Wall and -Wextra. Why? Because too many of clang's warning switches have names that have little to do with what they actually warn about. One in particular has to do with it finding duplicate selectors in different classes. I can never remember what it's called, but it's very annoying when you need to find it to disable it. Even worse, when you disable that particular flag, it disables a whole bunch of ot…
Whenever I am involved in build setups for C or C++ projects, -Wall, -Werror and static analysis are always part of the build.
It is the only sane way to give C and C++ the same strong typing that other languages enjoy since birth.
Quite useful in projects where due costs, most developers are not that experienced.
I am yet to do a Objective-C project, but I would use the same approach.
Re: Compiler Warnings for Objective-C Developers
#8I never do -Wall and -Wextra. Why? Because too many of clang's warning switches have names that have little to do with what they actually warn about. One in particular has to do with it finding duplicate selectors in different classes. I can never remember what it's called, but it's very annoying when you need to find it to disable it. Even worse, when you disable that particular flag, it disables a whole bunch of ot…
"I can never remember what it's called, but it's very annoying when you need to find it to disable it."
These days, clang will tell you what a warning is called any time it gives you one. If you ever need to disable a warning, make it happen (which you probably already did, otherwise why would you need to disable it?) and then just read the error message to see what flag to use to disable it.
Re: Compiler Warnings for Objective-C Developers
#9I never do -Wall and -Wextra. Why? Because too many of clang's warning switches have names that have little to do with what they actually warn about. One in particular has to do with it finding duplicate selectors in different classes. I can never remember what it's called, but it's very annoying when you need to find it to disable it. Even worse, when you disable that particular flag, it disables a whole bunch of ot…
This is so horribly wrong.
Firstly, when clang warns you of an error, it tells you the switch it uses to highlight that error, the disabling flag is then "-Wno-$switch" (or simply use a clang pragma to disable the warning: http://stackoverflow.com/questions/7017281/performselector-m...)
Secondly, the errors reported by -Wall and -Wextra are likely to be program bugs / bugs further down the line.
Thirdly: I upgraded my compiler on my CI system, I'd damn well want to know about new errors!
Re: Compiler Warnings for Objective-C Developers
#10'Treat warnings as errors' is the greatest thing since shirt pockets. I've found that most warnings are really latent errors. I've been using this setting for as long as I've been compiling with GCC/LLVM, going back to gcc 2.x. Whenever I take over a new project I immediately endeavor to fix all the warnings. The reason is simple: I've spent too much time chasing bugs that were directly related to a specific warning…
The build machine should treat warnings as errors but for local builds warnings are acceptable. You know they can't be checked in but they don't get in your way and slow you down while writing new code.