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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
