implicit QChar constructors

[Dirk Mueller]

On Mit, 22 Jan 2003, Oswald Buddenhagen wrote:

> yes, gcc (both 2.95 and 3.2.x) does this all over the place. seems
> pretty braindead to me, considering that optimizing this away should be
> almost trivial.

yes, gcc should be able to detect that the constructor is a pure function 
(has no side effects). so as it can do strength-reduction in similiar cases, 
I don't see why it doesn't do that here. Compiler guru, if you're listening, 
speak up. 

> however, performance does not suffer from it; the code just gets
> bigger. both the instruction decoding and the dead store are done in
> parallel with the "real" instructions on any modern processor.

true, redundant stores are not of big impact on modern processors. Thats why 
I prefer using "?" over if() even if the else part is redundant.. 

> still it seems rather braindead ... bcc 3.1 optimized such trivial
> things better - 12 years ago ...

Yes, exactly my thinking as well. I remember that those "old broken 
compilers" produced code that was much better optimized than the output I 
can see with gcc :-((

The world needs more gcc developers..

> just an optimization hint, which is often applicable: if you are
> _certain_ that a position does not exceed a qstring's length, don't use
> [], but .unicode()[] instead:

good one. I was hoping that Qt would adopt the STL semantics of operator[] 
vs at(), and I think they did at some point in the past. but now they 
changed it apparently :-((


-- 
Dirk (received 47 mails today)