inefficient QString coding practice

Richard Smith kde at
Sat Mar 13 16:16:42 GMT 2004

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:

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.


More information about the kde-core-devel mailing list