kdelibs/kdeui

[Lubos Lunak]

On Sunday 21 April 2002 13:22, Dirk Mueller wrote:
> On Son, 21 Apr 2002, Lubos Lunak wrote:
> >  So it can be changed to be non-inline. I don't think there will be any
> > serious performance hit. Or we can drop gcc-2.95 >;) .
>
> Can you please enlighten me on the actual problem with gcc-2.95 ? using
> seems to compile here.

 class A
    {
    public:
        virtual void foo( int ) const;
    };

class B
    : public A
    {
    public:
#if 1
        using A::foo;
#endif
        virtual void foo( int );
    };

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

$rpm -q gcc
gcc-2.95.3-136  (the one in SuSE7.3)

>
> > > is it to get rid of the overloaded-virtual warning ? just ignore such
> > > false cases then. There's a reason why it is not enabled by default in
> > > --enable-warnings.
> >
> >  This is a wrong way of doing things.
>
> Please ? I'm surprised to see such a comment from you, Lubos. The warnings

 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.

> of -overloaded-virtual are mostly false and it only helps to enable them
> sometimes, go through all of them and see which ones are real hits (or when
> you suspect a virtual signature mismatch type of error in your code).

 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). And 
all these warning can be fixed just like this one. IMHO it's better to 
completely skip the suspecting part by not making a mistake at all.

>
> There are so many false hits, and working around them in the way it was
> done here in kdelibs is completely wrong. It screws up binary compatibility
> in the worst possible way. In no way this is acceptable just to ignore
> certain types of warnings.

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

>
> If you want to find the useful warnings, write a small "read build log"
> script like I did, that throws away the useless stuff and only prints the
> filename, the location of the file, the line and the kind of warning.

 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.
 CDBakeOven comes to mind as a good example, in case you missed George 
Staikos' moaning for hours on IRC while he was trying to get that thing at 
least to compile (the problem there were mainly due to QT_NO_ASCII_CAST etc. 
IIRC).

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

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