[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.


http://reviews.llvm.org/D18271





More information about the cfe-commits mailing list