inefficient QString coding practice

[Eva Brucherseifer]

On Saturday 13 March 2004 17:16, Richard Smith wrote:
> On Saturday 13 March 2004 3:51 pm, Eva Brucherseifer wrote:
> > On Saturday 13 March 2004 14:38, Thiago Macieira wrote:
> > > Dr. Juergen Pfennig wrote:
> > > >If we look into QT's source code, we find that QT would handle
> > > >
> > > >  if( extension == ".wav")
> > > >    ...
> > > >
> > > >much more efficient, because it has an overloaded == operator for
> > > > "const char*". Here is the source from qstring.cpp:
> > >
> > > Only if QT_NO_CAST_ASCII isn't given. If it is given, then all the
> > > implicit const char* to QString conversions are withheld.
> >
> > Ther is no implicit cast involved. You have a member function available
> > for exactly the parameters given. So no cast here and there shouldn't be
> > any problem with the QT_NO_CAST_ASCII flag at all.
>
> Not true. Look at qstring.h. The (actually non-member) comparison operator
> is only available if QT_NO_CAST_ASCII is not defined. And rightly so -
> consider the following:

Yes - and I also should have read the second part of the  sentence I answered 
to :-|

>
> if ( extension == charPointerCouldBeUtf8 )
>
> If you allow an implicit assumption of ascii here, you will get incorrect
> results. So, as Harri Porten correctly surmised, some sort of explicit
> compareWithLatin1() is needed. Alternatively, how about a class
> latin1Comparison, used thusly:
>
> if ( extension == latin1Comparison( other ) )
>
> The implementation of this is simple: just store the char pointer in the
> class, then perform the operator==( const QString &, const char *) in the
> comparison operator for latin1Comparison (that .cpp file will need to
> #undef QT_NO_CAST_ASCII before including qstring.h of course). This is
> efficient and easily readable.

You can then have a member function implementing the whole algorithm itself. 
Undefining a define is imho not a good solution. It's ugly. 
A global function compareWithLatin1() is also nice. 

The good thing is, that you can easily do a global search&replace with both 
once Qt4 is there. I just wonder wether it's worth to introduce a new API 
item as a temporary solution for only one major KDE release...

Greetings,
eva

>
> Thanks,
> Richard