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.