Re: [boost] Warning policy? local variable hides (i.e. shadows) global variable

Subject: Re: [boost] Warning policy? local variable hides (i.e. shadows) global variable
From: Rob Stewart (rob.stewart_at_[hidden])
Date: 2015-01-15 10:19:12

On January 15, 2015 8:49:59 AM EST, Andrey Semashev <andrey.semashev_at_[hidden]> wrote:
> On Thu, Jan 15, 2015 at 4:11 PM, Beman Dawes <bdawes_at_[hidden]> wrote:
> > GCC and Clang have had a warning for years (-Wshadow): "Warn
> whenever
> > a local variable or type declaration shadows another variable,
> > parameter, type, class member (in C++), or instance variable (in
> > Objective-C) or whenever a built-in function is shadowed."
> >
> > VC++ 2015 (aka 14.0) Preview has now added a similar warning, C4459.
> >
> > The process of clearing these shadow warnings occasionally finds
> bugs
> > that are otherwise difficult to detect. Peter Dimov and I have both
> > found bugs in our code in the process of clearing the new C4459
> > warning. Even though most of the warnings don't actually signify
> bugs,
> > I'm finding that clearing them makes code clearer and less
> confusing,
> > particularly code I haven't looked at in a long while.
> >
> > Should Boost have policy to clear these warnings?
> >
> > A lot of the warnings involve function argument names. Should we
> have
> > a guideline to prevent shadow warnings?  A convention for argument
> > names would make it easier to submit pull requests. Possible
> > guidelines:
> >
> > * Prefix function argument names with "a_". Rationale: The "m_"
> prefix
> > for member names has been a success.

Really? I think it's ugly.

> > * Suffix function argument names with "_". Rationale: Short and less
> > distracting than "m_" prefix.

I use a _ suffix for data members and a _ prefix for formal parameters.

> > Thoughts?
> 
> Despite that the warnings should probably be fixed, I don't think
> there is need for a naming policy.

Normally, I'd dismiss such warnings as unwanted noise, but given Beman's anecdotal evidence of the benefit of addressing them, I'm inclined to agree that they should be addressed.

 > I'm sure any guideline will
> contradict someone's habits or preferences, and will be difficult to
> maintain.

Exactly

> As for the particular issue, it's probably better to mangle the global
> variable names (my preference is "g_") rather than function arguments
> or local variables. Globals are much more rare and their names should
> be chosen carefully anyway.

I prefer suffixes for such things, but any convention will work.

___
Rob

(Sent from my portable computation engine)