QString latin1 comparision

[Thiago Macieira]

Juergen Pfennig wrote:
>I would understand if you would say you want some no-op macro to flag such
> a situation or use the macro that comes with qt4 (or a dummy for that).
> But QString::fromLatin1() is not a no-op and it is unefficient because it
> creates a temporary QString object.

That's why Qt4 has QLatin1String. It's a lot more lightweight and QString 
has overloaded operators to QLatin1Strings.

>KDE is slow enough and has more than enough bugs. Why trying to make it
>slower? Please have a look at win2003 and compare the speed to KDE! QT is
> not stupid and today the NO_ASCI_CAST makes little sense, as QT has
> overloaded Latin1 functions almost everywhere.

That is true. But we have to be aware that not all overloaded functions 
taking 'const char*' work in the same manner.

QString::QString(const char*) uses QTextCodec::codecForCStrings
operator==(const QString&, const char*) assumes it's Latin1
and so on

Hence why properly labelling the encoding is preferrable.

>(1) using UTF-8 strings everywhere instead of us-ascii (does gcc like
> this?)

That's already how it is.

>(2) moving away from GCC - here: supporting UNICODE string literals.

Not an option because, as other people have said, sizeof(wchar_t) != 
sizeof(QChar).

-- 
  Thiago Macieira  -  Registered Linux user #65028
   thiago (AT) macieira (DOT) info
    ICQ UIN: 1967141   PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20041017/c9842681/attachment.sig>