[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:       Dirk Mueller <mueller () kde ! org>
Date:       2001-02-27 19:54:05
[Download RAW message or body]

On Die, 27 Feb 2001, Harri Porten wrote:

> > I noticed that Qt uses "int operator==(foo, bar)" while my C++ book
> > (Stroustrup) says something about "bool operator==(foo, bar)".
> "Almost only" for QChar, right ?

Thats were I noticed and investigated it (still looking into it on how to 
make the html tokenizer rocking fast ;-) ). 

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. 

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

> > I'm just wondering.. it seems to have a dramatic effect on code generation
> > for g++/gcc when changing the return type to "bool". strange world.
> Much more optimized I hope ?

sometimes, yes. In some cases it is 6 cheap + 1 expensive 
instruction (athlon only knows pairable cheap and nonpairable expensive instructions, 
that makes it easy :) ) replaced by 3 cheap instructions in other cases its 
rougly no change at all. gcc3 seems to have some serious bugs in the code 
generation so I maybe should check with a sane compiler first. If you 
know a bit of assembler you will still have a good laugh ;-)

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

but please go ahead for Qt 3, saves me preparing a patch for qt-bugs :)


Dirk

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