<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Apr 23, 2012, at 11:33 AM, Patrick Beard <<a href="mailto:beard@apple.com">beard@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Apr 10, 2012, at 1:22 PM, Evan Wallace wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><div>I guess the warning I was envisioning was more of a stylistic warning. The equivalent warning from gcc is -Weffc++ which includes warnings about violations of several style guidelines from Scott Meyers' book "Effective C++, Second Edition" including this warning (always put all members in the initializer list). It includes a few other warnings and is helpful in preventing mistakes, especially for beginners, but generates a lot of noise when run on large existing projects and unfortunately can't be split into separate, fine-grained warnings. The warning in this patch is much more targeted but makes the choice to reject some valid code instead of silently ignoring invalid code. It was more targeted for beginner to intermediate users of C++ and not for large, highly optimized projects. Maybe this wants to be two warnings, one for initializer lists as it is currently and one that attempts to trace uninitialized members to the end of each constructor but doesn't warn when it isn't sure?</div></span></blockquote></div><br><div>Having spent a little bit of time trying to track down a bug that was caused by unitialized POD data members, I'd also like to see your patch committed as an opt-in warning.</div></div></blockquote><br></div><div>When I use this patch, it breaks one of the other tests:</div><div><br></div><div><div>FAIL: Clang :: SemaCXX/default-constructor-initializers.cpp (3644 of 4580) </div><div>******************** TEST 'Clang :: SemaCXX/default-constructor-initializers.cpp' FAILED ******************** </div><div>Script: </div><div>-- </div><div>/private/var/tmp/compiler.build/Release+Asserts/bin/clang -cc1 -internal-isystem /private/var/tmp/compiler.build/Release+Asserts</div><div>/bin/../lib/clang/3.2/include -fsyntax-only -verify /private/var/tmp/compiler/llvm/tools/clang/test/SemaCXX/default-constructor-</div><div>initializers.cpp </div><div>--</div><div>Exit Code: 1</div><div>Command Output (stderr):</div><div>--</div><div>error: 'note' diagnostics expected but not seen: </div><div> Line 54: first required here</div><div>1 error generated.</div><div><br></div><div>Here's the patch I'm using:</div><div><br></div><div></div></div></body></html>