[PATCH] D18271: Avoid -Wshadow warnings about constructor parameters named after fields

Ben Craig via cfe-commits cfe-commits at lists.llvm.org
Wed Mar 23 12:18:21 PDT 2016

bcraig added a subscriber: mclow.lists.
bcraig added a comment.

> > Not dblaikie, but I've used the GCC version of -Wshadow on reasonably large code bases before.  The ctor pattern that this is trying to squelch was certainly a significant portion of the warnings, particularly when (old) boost headers got involved.


> > 


> > I believe that newer versions of boost (~1.50 and newer?) attempt to be -Wshadow clean in the headers.



> Did squelching this ctor pattern find any bugs? Do you know if boost would miss the warning firing in this case?

I don't recall fixing any bugs with the ctor pattern.  I can only recall two different classes of things that I have fixed that were flagged with -Wshadow.

1. Long, horrible, deeply nested method, with a local that was trivially shadowing a different local in a larger scope.
2. Mutex lock guards and similar "sentry" objects.  "std::unique_lock<std::mutex>(name_of_a_member);"  The user wanted that to lock 'name_of_member' and release it at end of scope, but instead it declared a default constructed unique_lock called 'name_of_a_member' that shadows the member variable.  I've had to fix this kind of bug a number of times, and it is my main justification for turning on -Wshadow in the first place.  On that note, I'm really looking forward to the day I can say "auto guard = std::unique_lock(name_of_member);" to effectively get rid of this problem.

I doubt boost would miss the warning, and probably wouldn't even notice (barring overlapping list membership).  If you're really wondering if boost would care / notice, @mclow.lists would have a better idea.


More information about the cfe-commits mailing list