Rixstep
 About | ACP | Buy | Industry Watch | Learning Curve | News | Products | Search | Substack
Home » Industry Watch » The Technological » Hall of Monkeys

Disable a Warning

Great things seen in small words.

FROM : charlie
DATE : Mon Mar 24 03:29:47 2008

How do I disable this warning?...

"local declaration of 'varname' hides instance variable"

- Chuck

FROM : Andrew Farmer
DATE : Mon Mar 24 03:35:07 2008

On 23 Mar 08, at 19:29, charlie wrote:
> How do I disable this warning?...
>
> "local declaration of 'varname' hides instance variable"

Use a different name for either the local variable or the instance
variable. This is a serious enough warning that I really wouldn't
recommend disabling it.

FROM : charlie
DATE : Mon Mar 24 03:56:03 2008

Thanks.

I understand the reason behind the warning.

I've coded around the namrspace conflict.

Now I just want to suppress the warning.

- Chuck

FROM : charlie
DATE : Mon Mar 24 04:59:04 2008

For years, I've been doing this:

- (void)setController:(id)_controller
{
  if (!_controller)
  {
    return;
  }
  controller = [_controller retain];
}

It has always irked me having to work around namespace conflicts
between method args and instance variables.

So, today I decided to try this for my next project...

- (void)setController:(id)controller
{
  if (!controller)
  {
    return;
  }
  self->controller = [controller retain];
}

I works fine.  But does not fix the warning itself.

So, the question stands.... How do I suppress the warning.

- Chuck

On March 23, 2008, Michael Watson wrote:

> If you've rewritten your code to fix the conflict, you shouldn't be
> getting the warning. What does "coded around the namespace conflict"
> mean, exactly?
>
>
> --
> m-s

FROM : j o a r
DATE : Mon Mar 24 05:12:57 2008

Chuck,

* You really shouldn't suppress these warnings

* If you use ObjC 2.0 properties you don't have to write those
accessors in the first place, and

* If you use ObjC 2.0 properties, you can use this form without
warnings:

   self.foo = foo;

j o a r

FROM : Sherm Pendley
DATE : Mon Mar 24 05:18:50 2008

You suppress the warning by fixing the problem it's warning you about. Yes,
it's just that simple.

For example, the above could be rewritten as:

- (void)setController:(id)newController {
    if (!controller) return;
    controller = [newController retain];
}

sherm--

FROM : Dave Hersey
DATE : Mon Mar 24 05:49:57 2008

> For example, the above could be rewritten as:
>
> - (void)setController:(id)newController {
>    if (!controller) return;
>    controller = [newController retain];

I think the if (!controller) check was for the passed-in value, not
the instance variable, but there lies the confusion about using the
same name for instance variables and parameters like this.

I can't think of any reason NOT to take the time to type a few more
characters in that parameter name to make things clear. You've already
spent much more time trying to work around the warning than fixing it
like Sherm says.

Also, I'm guessing that this method is only called once, because
otherwise your memory management is hosed. I'd normally do these
retaining setter methods like this, just out of habit:

- (void) setController: (id) aController
{
   id    tempObject = m_controller;     // m_controller is the instance var.
   m_controller = [aController retain]; // retain before releasing the old value in case m_controller
   [tempObject release];                // and aController are the same.
}

I realize it's a controller in this case so you're probably only
calling it once, but it's very little extra typing to write it safe.
Finally, you don't need to check for nil in your code if you're only
calling it once, because [nil retain] == nil.

So, you could write your code like:

> - (void)setController:(id)newController {
>    controller = [newController retain];
> }

- d

FROM : charlie
DATE : Mon Mar 24 05:55:59 2008

I didn't ask for advice.

I asked a simple question.

And it still stands.

- Chuck

FROM : charlie
DATE : Mon Mar 24 06:04:41 2008

It's not about extra characters I have to type.  It just looks fugly to
me.  It always has.  And I'm not saying this solution is perfect.  It's
ugly too.  Just less ugly to my eyes.  In fact, I may end up hating it
after this project.. but I want to at least try it once and see how I
feel about it afterward.

"aController" is exactly what I'm tring to avoid, by the way.  I want
to call it "controller", nothing less, nothing more.  Same goes for the
instance variable.

This is why I didn't want to reveal **why** I want to suppress this
warning.  Because everyone feels compelled to pitch in their 2 cents on
this tangent subject which has already been explored and closed on my
end.

I could care less what anyone else thinks about this decision.

I simply want to know how to suppress the warning.

That's it.

- Chuck

FROM : Daniel Jalkut
DATE : Mon Mar 24 06:11:58 2008

On Mar 24, 2008, at 1:04 AM, charlie wrote:
> This is why I didn't want to reveal **why** I want to suppress this
> warning.  Because everyone feels compelled to pitch in their 2 cents
> on this tangent subject which has already been explored and closed
> on my end.
>
> I could care less what anyone else thinks about this decision.
>
> I simply want to know how to suppress the warning.

Look in your build settings. Turn off the "Hidden Local Variables"
warning:

"Warn whenever a local variable shadows another local variable,
parameter or global variable or whenever a built-in function is
shadowed.  [GCC_WARN_SHADOW, -Wshadow]"

Unfortunately, it's harder to turn off the warnings of well-meaning
developers who just want to save you from making a foolish move. You
might thing twice, three, four, five times before persisting in being
so indignant about this decision, especially as a variety of people
start to chime in with the same message.

They're just trying to save you from doing something dumb. Your
attitude in the past few messages makes it sound like you're much more
concerned about this obsessive naming habit you've got than you are
about the safety of your code. That, combined with the tone of your
reaction makes it pretty unlikely that people will jump to help you
out in the future.

And yes, when you ask for the help of a community, you take the advice
you can get, even if it does include foreboding warnings about the
wrongness of what you're trying to accomplish.

Warning: you might be doing something really dumb by turning off that
warning. Enjoy!

Daniel

FROM : Daniel Jalkut
DATE : Mon Mar 24 06:14:54 2008

On Mar 24, 2008, at 1:11 AM, Daniel Jalkut wrote:
> Look in your build settings. Turn off the "Hidden Local Variables"
> warning:

Whoops ! Looks like I was wrong about that.  Doesn't actually disable
the particular instance-var hiding warning.

So maybe even the compiler refuses to let you turn off this well-
intentioned warning.

Daniel

FROM : Dave Hersey
DATE : Mon Mar 24 06:31:29 2008

Right... Sorry, I misunderstood. So, you want to continue using your
flawed coding style, but not be warned about it? Got it.

If it's really important to you, send an incident to DTS and pay them
$195 for the answer. I suspect they'll tell you what we've told you.

Otherwise, I'd ask on the Xcode list which is where this question now
belongs, since you're asking about compiler warnings and not Cocoa
development.

Out of curiosity, why did you think that adding an underscore to both
the local and instance variable names, but still keeping them the same
would fix this problem?

- d
...who is up to 4 cents now.

FROM : Jens Alfke
DATE : Mon Mar 24 07:03:03 2008

On 23 Mar '08, at 10:04 PM, charlie wrote:

> I could care less what anyone else thinks about this decision.
> I simply want to know how to suppress the warning.

That statement gives the impression of treating the members of this
mailing list as though they were some kind of natural-language answer-
bot, not as human beings.

If that's the sort of interaction you want, try searching the GCC
compiler documentation in /Developer, which exhaustively lists every
warning and the flags to enable or disable it. Search algorithms don't
not talk back and are not programmed to give you coding advice.
Humans, on the other hand, will consider the context beyond the
literal question you asked, and address that context if it's
significant enough. As it is in this case.

-Jens

FROM : John C. Randolph
DATE : Mon Mar 24 08:14:11 2008

On Mar 23, 2008, at 10:31 PM, Dave Hersey wrote:

> If it's really important to you, send an incident to DTS and pay
> them $195 for the answer. I suspect they'll tell you what we've told
> you.

Speaking as a former Apple DTS engineer, I would ask you not to advise
Charlie to waste their time in this manner.

-jcr

FROM : John C. Randolph
DATE : Mon Mar 24 08:18:07 2008

On Mar 23, 2008, at 10:04 PM, charlie wrote:

> I could care less what anyone else thinks about this decision.


The phrase you're trying to use is "couldn't care less".  Think about
it for a second, try to parse it.

In any case, if you're going to be surly when people who know more
than you do give you advice, then you should probably just unsubscribe
from cocoa-dev.

-jcr

FROM : Dave Hersey
DATE : Mon Mar 24 08:45:24 2008

> Speaking as a former Apple DTS engineer...


Maybe you had my old office.

 : )

- d

FROM : charlie
DATE : Mon Mar 24 06:46:45 2008

"Right... Sorry, I misunderstood. So, you want to continue using your
flawed coding style, but not be warned about it? Got it."

Exactly.  And.. I'm fully admitting that this is a goofy workaround,
but I want to try it nonetheless.

"If it's really important to you, send an incident to DTS and pay them
$195 for the answer. I suspect they'll tell you what we've told you."

I've worked with DTS before, and the vibe is very helpful.  They would
probably remind me of the downside to doing it this way, but if there's
a way to disable that warning, they will tell me what it is.

"Otherwise, I'd ask on the Xcode list which is where this question now
belongs, since you're asking about compiler warnings and not Cocoa
development."

Good point.  I think youre absolutely right.

This will give me a chance to think about how to better phrase my
question too.

- Chuck
About | ACP | Buy | Industry Watch | Learning Curve | News | Products | Search | Substack
Copyright © Rixstep. All rights reserved.