[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