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
> > 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
> > 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
> > I'm finding that clearing them makes code clearer and less
> > 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
> > 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_"
> > 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
> 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.
(Sent from my portable computation engine)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk