[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: stupid C++ question / operator overloading / Qt
From:       Harri Porten <harri () trolltech ! com>
Date:       2001-02-27 20:22:03
[Download RAW message or body]

Dirk Mueller wrote:
> 
> I didn't check all overloaded operators yet. I was hoping that there is some
> gcc -Warning about that but apparently there isn't :-( So there might be
> more instances of partially wrong signatures.

I grepped for them as good as I could. Most where in qstring.h.
 
> > > Are there compilers out there needing this specific return type ?
> > In old code you'll often find code that defines operator==() without any
> > return type at all. I guess that it comes from a time where bool didn't
> > exist and current compilers allow the defaulting to int for
> > compatibility reasons.
> 
> Well, good explanation. but still "operator==()" and "int operator==()"
> should be distinguishable for a compiler ;-)

That's what I mean with compatibility reasons:
 
> > Unless someone holds me back I'll fix this
> > for 3.0 as 2.x is out of question for obvious reasons.
> 
> Changing return type should be binary compatible, especially for inline'd
> methods.

I remember this "common rule" after sending my mail. I wouldn't be my
job (pun intended;) an *all* compilers.
 
> but please go ahead for Qt 3, saves me preparing a patch for qt-bugs :)

Already fixed. Thanks for finding this.

Harri.

P.S. In case you got your initial hint from gprof: My experience with
(other) profilers is that small but often called functions may blow up
the statistics. I guess that the overhead introduced by the profiler may
cause quite some error if not balanced properly.

[prev in list] [next in list] [prev in thread] [next in thread]