kdelibs/kdeui

[Lubos Lunak]

On Sunday 21 April 2002 14:52, Dirk Mueller wrote:
[snip]
> >  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.

 No, it's not clean, otherwise there wouldn't be a valid warning. Ideally, 
there should be of course 'using', but since it doesn't work with the 
oficially recommended gcc version, overriding instead is a workaround, that 
maybe doesn't look 100% perfect, but does the job and doesn't break anything.

>
> >  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).

 Intended hiding of virtual methods, hmm? And faults can be fixed, or should 
they stay there forever? They could have been fixed for Qt3.

>
> >  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.

 I said it can be non-inline, without any serious performance hit or whatever.

>
> >  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.

 But such people will be different from those who now don't see the warnings - 
those who don't see the warnings now often don't know how to turn it on or 
even that they can turn it on, while people who will use --disable-warnings 
and commit code with warnings are ... well ... @#%#!
 And I'm not talking only about CVS - every KDE app is developed based on the 
way it's done with code in CVS, so if Joe Developer is starting to develop 
his first KFooApp, Joe Developer will most probably have the same settings.

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

-- 
 Lubos Lunak
 llunak at suse.cz ; l.lunak at kde.org
 http://dforce.sh.cvut.cz/~seli