This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug c++/18016] Warn about member variables initialized with itself


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]