inefficient QString coding practice
Richard Smith
kde at metafoo.co.uk
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.
Thanks,
Richard
More information about the kde-core-devel
mailing list