inefficient QString coding practice

[Thiago Macieira]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dr. Juergen Pfennig wrote:
>On Saturday 13 March 2004 14:38, Thiago Macieira wrote:
>> Only if QT_NO_CAST_ASCII isn't given. If it is given, then all the
>> implicit const char* to QString conversions are withheld.
>
>So you say the eventual use of QT_NO_CAST_ASCII (which would probably
> break 90% of the code in kdelib) is so important that the inefficient
> coding style should be used?

78% of the statistics are invented :-)

You have to weigh the inefficiency caused by the comparisons to the 
inefficiencies caused by the implicit casting -- as well as wrongly 
encoded strings.

QT_NO_CAST_ASCII is a tool for the developers to see if they are doing 
mistakes in handling QStrings. If I'm not mistaken, Qt compiles itself 
with that flag.

Now, I had thought that QT_NO_CAST_ASCII only prevented the automatic 
QString::fromAscii and QString::ascii from being used. Implicit casting 
in those cases are no different than QString::fromLatin1 or 
QString::fromUtf8. There's only benefit: mark conversion to Unicode as 
such.

Your example is a case where they aren't used. IMO, they shouldn't be 
withheld.
- -- 
  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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAUxenM/XwBW70U1gRAqWmAKChEgXUXf5W7wPt91aFHzkJkwnXDQCeNZ0r
u7is0MM/oAf9WfgWO2MJdX4=
=vY4n
-----END PGP SIGNATURE-----