This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug c++/18016] Warn about member variables initialized with itself
- From: "redi at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Wed, 22 Dec 2010 14:40:25 +0000
- Subject: [Bug c++/18016] Warn about member variables initialized with itself
- Auto-submitted: auto-generated
- References: <bug-18016-4@http.gcc.gnu.org/bugzilla/>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18016
--- Comment #11 from Jonathan Wakely <redi at gcc dot gnu.org> 2010-12-22 14:40:07 UTC ---
(In reply to comment #10)
> Like others commenting here, I don't understand why a(a) should not warn only
> with -Winit-self.
I agree with Andrew, the a(a) mistake should always warn, it should be
independent of -Winit-self, which exists so that -Wuninitialized doesn't warn
about the common (but questionable) practice of self-initializing automatic
variables to silence warnings.
As I said in my mail to gcc-patches, if you want to leave a member variable
uninitialized, just don't give it a mem-initializer in the constructor. Giving
it a self-initializing one is just perverse. (The case of automatic variables
is different, you can't just not declare it to leave it uninitialized.)
Also, as -Winit-self is broken I didn't want to tie this bug to a broken
feature that might be changed to not work for C++.
> On the other hand, I always thought that Winit-self is a bad
> idea. Although the patch does not fixes many cases and thus, we shouldn't close
> this PR, it is better than nothing.
>
> About the location, don't we have a better location at that point?
>
> I am thinking that
>
> X() :
> j(j), #2
> i(i) #3
> {}
>
> should give warnings in #2 and #3.
There are various open bugs about that, e.g. PR 43064, I don't think it's
possible at the moment.