kdelibs/kdeui

[Dirk Mueller]

On Son, 21 Apr 2002, Lubos Lunak wrote:

> a.cpp:15: cannot adjust access to `void A::foo(int) const' in `class B'
> a.cpp:14:   because of local method `void B::foo(int)' with same name
> a.cpp:4: warning: `A::foo(int) const' was hidden
> a.cpp:14: warning:   by `B::foo(int)'

Hmm, ok, I didn't try this variant. yes, I get that too. 

>  Why? Just because I know how to use ugly hacks when needed doesn't mean that 
> I like code looking written like pigs. While I'm not completely happy about 
> 100% code purists, there are many people whose first coding experience is KDE 
> and I don't see anything wrong about trying a bit to make them write clean 
> code.

The previous code is _clean_ already. adding "useless" (hidden) virtual 
overloads is not making the code cleaner, just the opposite IMHO. 

>  None of the warnings is false, everytime there's such warning a method was 
> really hidden (the other thing is if it's used in that context or not).

Of course, but most of the time this hiding was intended (or we can't change 
it, i.e. faults in Qt design). 

>  It does not screw up binary compatibility. The only case where it changes 
> something is when the base's method was directly referenced, but it doesn't 
> really change anything, because the new method (that won't be called) doesn't 
> actually do anything besides calling the base's method. How does this break 
> binary compatibility 'in the worst possible way'?

by inlining a virtual method we can not change it anymore. 

>  It's not just that I want to find the warnings, I think all should find the 
> warnings, for reasons listed in the previous mail. In fact I think 
> --enable-warnings should be on by default, and those not willing to have it 
> would disable it explicitly. I see way too many 3rd party KDE apps spitting 
> hundreds of warnings just when compiled with -Wall. There are(were?) even KDE 
> CVS developers not knowing about --enable-warnings.

Yes, does that prevent people from committing broken code? no. When we 
change the default to --enable-warnings, those people who care about the 
1% performance penality will immediately switch to --disable-warnings and 
continue committing broken code. 

>  BTW, if that script is generic enough, it could go in kdesdk and be 
> advertized appropriately.

Well, its rather simple, it just strips "junk" from the build log and shows 
you the rest. 


Dirk