Separate names with a comma.
Discussion in 'Mac Programming' started by farmerdoug, Feb 28, 2013.
Can I turn off the Xcode's unused variable warnings?
you can use
i think place it above the declaration of the variable
Or you could just use the variable or erase it
Thanks but I'm really looking for a complier switch.
Does this help: http://useyourloaf.com/blog/2011/09/20/disabling-clang-compiler-warnings.html
Should do it in gcc. Not sure if clang respects these the same way.
Is there a place in Xcode where I can add that?
The blog I linked implies it is exposed in the Xcode UI.
Don't. Fix the warnings. Warnings are your friend. They show you bugs in your code. If you get warnings, fix the reason for the warning.
You forgot who you're talking to!
I usually fix unused variable warnings with this "//" "/* */" also works, but it is more effort to do and undo.
I use similar parts of the same code over and over again. However, while the overall set of variables may be large, the set used in any one program maybe small resulting in a large list of warnings being printed out. I think these warnings I can safely do with out.
How do do this.
If you put all your declarations in a header file, you don't get the warnings.
Sounds like some code for a project I inherited. All the code was in the .h file just because it was easier that way.
The preprocessor lets you effectively comment code out on the fly using #ifdef.
So, let´s summarize.
You are not following normal coding standards. And this "laziness" makes the compiler issue warnings. And now you want to remove the warnings.
Hmm. Not the way the rest of us would do it. In my experience this sooner or later jumps up and bites me. You might be different of course.
Personally I would instead divide the program into separate "modules" *), separately compiled and each with its own set of global variables. This means that the variables will only be created if the module is actually used and actually linked into the program. Then I define the interface to that module in a .h file. Generally, I would not expose the global variables outside the module. This is one way to allow me to know which part influences which.
There is one essential tool for making this work, make. A make file (when done right) ensures that the different modules are up to date and stored in a library. The linker then fetches the referenced modules from the library.
*) Note: I use the word "module" a bit losely here as it is not really a concept in c.
Okay, look. Let's put things into perspective here, people. There are warnings and then there are warnings. Converting a float to pointer without a castyeah, that's something I want to know about and almost certainly need to fix. Unused variables? Please. What's the risk here, that I run out of stack space? Whatever.
If the guy knows what he's doing, and has explained exactly why he wants to do it, why hassle him about a simple question? Because it doesn't meet your arbitrary standards for what is considered proper? Either get off your high horse and help him with the question he asked, or keep your snobbish comments about what you consider to be best practice to yourselves.
Are you telling us what to post here? Seriously? After insulting everyone twice ("get off your high horse", "snobbish comments")?
By the way, your risk assessment is totally and utterly wrong.
You would not be able to compile it, as it would generate a compile error. With some elaborate casting you may be able to trick the compiler to shut up, but why on earth would you want to?
Hmm. How did you become angry?
English might not be my first language, neither is c my first computer language, so I migh miss some finer points. My answer was meant as a friendly discussion relating to my personal experiences.
I was referring to personal experience where what I though was warnings turned out to create errors. Personally, after that and other mishaps, I now change my source code until there are absolutely zero warnings -- except when it is totally unavoidable from some reason.
I was also considering that a if, possibly maybe, the Op does not know how to read the man page for the compiler or not beeing able to read the C standard document, might, just possibly, not be up to the "standard" way of coding C. This does in general consist of dividing the source code into several .c and .h files and also placing recurring stuff into librarys. All tied together with make.
Why on earth would you keep unused variables in the first place? the idea is to make code better, if you pollute it with unneeded junk you run into performance hits. Granted it may not be noticeable in this situation, but thats just unneeded waste that no one should be in the habit of doing
Here's the thing: farmerdoug knows he's not writing maintainable code. He's not worried about runtime or memory efficiency. He's not worried about best practices. He wants an answer. If he can cobble together a working solution, he's more than happy. If he does put interest into any of the above, it's prioritized well below getting a result.
Could he save time, do things more efficiently, save frustration, etc. with some investment? Sure, but it's not his thing. He might pick up a tip or trick from us here or there, but he doesn't want to be a programmer, he wants to solve some problems. If it uses excessive memory and takes n^4 time instead of nlogn that's fine. The machine is a tool to do his bidding, its resources are not precious.
Do I want to maintain his code? Nope.
Do I want to use his code? Not really.
Does it hurt me that he approaches code this way? No.
Generally I stress doing things "right", because I want to contribute to the collective programmer karma. I hope making us all better will mean better software to use, and better co-workers. In farmerdoug's case? Not an issue. Preaching and lecturing is not going to help anyone.
I honestly don't know why he doesn't try doing his work in something like Python - he doesn't have a grasp of the C language and he could probably get more done instead of mucking around with something he doesn't know how to use correctly
Yes you can farmerdoug, go to the build setting for either the project or target, then scroll down until you see the section for Apple LLVM Compiler 4.2 -Warnigs - All Languages, then the last listing in this section you will see the unused variable warning flag set to Yes as default, just change it to No.
Should you be doing it?
Not really, but hey if thats what you want, good luck with it.
I want the reason for the warnings in my code. Therefore I do not wish to "fix" them and make my code worse. You can ruin your own code if you wish, but don't recommend damaging mine.
You can print them in the debugger without having to modify the source of Debug builds. Very useful when looking inside complex code that can produce the correct results for the wrong reasons. Unlike merely commented code, the compiler will also spell check the names and syntax for you, and thus help reduce the likelihood of outright incorrect comments (which happens more than you would think.)
Nope. LLVM is smart enough to remove these code paths from an optimized release build.