Re: pragma nowarn
Re: pragma nowarn
- Subject: Re: pragma nowarn
- From: Alastair Houghton <email@hidden>
- Date: Wed, 12 Dec 2007 12:47:30 +0000
On 12 Dec 2007, at 12:17, William Bates wrote:
I'd say, "Warnings Are Usually A Good Thing™" But like anything
else, they can be overdone. Which is why we have switches to turn
them off. We're only taking about the granularity here.
"pragma no warn" is just a comment. Used sparingly, it communicates
to other humans (or the code writer, six months later), "I'm doing
something tricky here that I've thought about, but the compiler may
not get." Then it turns of the darn yellow flag that may well
distract attention from real problems.
I have yet to see a situation where there is genuinely a reason for
not changing the code to fix a warning, assuming that you don't enable
any of the sillier warning flags.
Broadly speaking I have two problems with #pragma no warn:
1. It is usually used inappropriately, to disable warnings where the
programmer can't figure out what the warning means or how to fix it.
Often this results in bugs.
2. It is often used in the blanket sense, rather than enabling or
disabling individual warnings. As a result, a future code change that
would normally generate a warning won't. Again, the result is bugs.
BTW, Alastair's position (all warnings on all the time) is the same
advocated by the author of an Evil Empire Bible, "Code
Complete," (Microsoft Press). Heresy, anyone?
My position is not "all warnings on all the time". Turning all GCC's
warnings on would be just plain silly, since some of the warnings are
themselves silly (which is why not all of them are included in the -
Wall or even -W -Wall settings).
My position is more that if a warning is worth having, it's worth
having everywhere, and that if you need to get rid of it, in 99.999%
of cases you should change your code so that it doesn't generate a
warning, rather than looking for a way to temporarily disable the
warning. The latter is treating the symptoms (the warning), not the
cause (the code).
IB 3.0 has decided static text needs to be bigger than before, and
now generates lots of spurious clipping warnings...
IB 3 isn't what we're talking about here.
a waste of time to "fix" since the complier itself may be 'fixed"
next version. Or consider the best way to take advantage of late
binding, the essence of Objective C, with constructs like:
if ([myObject respondsToSelector:@selector(optionalMethod:)])
[myObject optionalMethod: param];
without turning off "Incomplete Objective C Protocols" warning....
I have that warning turned on, and I have no instances of it in any of
my code in spite of writing statements like the one you give as an
example.
If you are getting such a warning, the solution is to be more specific
about the type of myObject, so that the compiler knows about your
optional method. If you don't do that, it may in some cases make the
wrong choices when deciding how to pass parameters to the method...
90% of the time that will result in an error because the type won't be
one that the compiler can coerce. But 10% of the time it will just do
the wrong thing.
You can also end up with problems depending on the return type of your
optional method (for instance, if it returns a floating point result
or a structure of some sort).
Worse, occasionally you'll find that your code will work on PowerPC
but not on x86, because of some artefact of the calling convention
used on one or other platform.
So #pragma no warn wouldn't be appropriate here, because the warning
in question may represent a genuine (and in some cases nasty) bug.
You should fix your code instead. The fix is in any case shorter than
writing #pragmas to disable the warning would be.
Kind regards,
Alastair.
--
http://alastairs-place.net
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden