<br><br><div class="gmail_quote">Le 11 avril 2012 04:00, Jordy Rose <span dir="ltr"><<a href="mailto:jediknil@belkadan.com">jediknil@belkadan.com</a>></span> a écrit :<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I do think this should still go in, even if it's off by default. Any easy checks could be included, any difficult checks should not.<br>
<br>
OTOH, we've run into things like this before, and the general rule has been that Clang is not in the habit of introducing new style warnings. The style warnings we have are generally ones that have historical precedent (-Wparentheses). So my personal positive preference may not match up with Clang's big-picture goals.<br>

<br>
The one thing that would make it nicer is a way to silence the warning without initialization, but I can't think of a good way offhand.<br>
<br>
My two cents,<br>
Jordy<br>
<div><div class="h5"><br>
<br>
On Apr 10, 2012, at 16:22, Evan Wallace wrote:<br>
<br>
> Thank you all for your responses and for the awesome feedback. I think there are a couple of different ideas in this thread. While it would be fantastic to try and find uninitialized values in arbitrary code, that would definitely be a much larger change and I don't think I'm up for that yet. It looks like -Wuninitialized currently follows the flow of uninitialized variables within a function and could probably be modified to also follow members not in the initializer list through the constructor. However, following flow into other functions can be very complicated and, as Matthieu brought up, it isn't possible in the general case because the source for some methods might not even be available. Such a diagnostic would end up being an approximation and would sometimes either have to reject valid code or silently ignore invalid code.<br>

><br>
> 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?<br>

><br>
> - Evan<br>
</div></div>> _______________________________________________<br>
> cfe-dev mailing list<br>
> <a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
<br>
</blockquote></div><br>FYI:<br><br>Just this afternoon I activated a build with -Wall -Wextra -Werror on gcc and I had to add a -Wno-missing-initializer because gcc erroneously warns on:<br><br>struct tm timepoint = {};<br>
timepoint.tm_year = 111;<br><br>saying that all members other than `tm_year` are not initialized. It is *really* annoying to put up with such false positives.<br><br>So I would be very interested in warning that is never wrong, and maybe Ted would approve of a specific -Wbeginner group to put warnings that are potentially wrong but really help beginners ?<br>
<br>-- Matthieu<br>