On terça-feira, 14 de fevereiro de 2012 15.03.34, Olivier Goffart wrote: > On Tuesday 14 February 2012 13:50:06 Johannes Zellner wrote: > > Hi, > > > > what is the reason for " DEFINES += QT_NO_CAST_FROM_ASCII " > > in the platformsupport.pro file? > > > > I just hit that and would like to understand why we have this > > inconvenience here. > > Ok, i don't know the specific on why it is there in platform support. The > rest of Qt just has QT_ASCII_CAST_WARNINGS
Actually, there are many parts of Qt with QT_NO_CAST_FROM_ASCII: $ git grep QT_NO_CAST_FROM_ASCII -- mkspecs src/\*.pr? | cat src/platformsupport/platformsupport.pro:DEFINES += QT_NO_CAST_FROM_ASCII src/plugins/platforms/windows/windows.pro:DEFINES *= QT_NO_CAST_FROM_ASCII src/plugins/sqldrivers/qsqldriverbase.pri:DEFINES += QT_NO_CAST_TO_ASCII QT_NO_CAST_FROM_ASCII src/sql/sql.pro:DEFINES += QT_NO_CAST_FROM_ASCII src/testlib/testlib.pro: QT_NO_CAST_FROM_ASCII \ src/tools/bootstrap/bootstrap.pri: QT_NO_CAST_FROM_ASCII \ src/tools/bootstrap/bootstrap.pro: QT_NO_CAST_FROM_ASCII \ Having it enabled is a good reason because: > Anyway, casting from char* to QString must be avoided on library code. > > the reason: > > if you have > > QString foo = file.readAll(); > > This compile fine, and even look right, but might be wrong. > because a char* do not say anything about the encoding. Is it latin1, utf8, > other? > > So Qt provide QTextCodec::codecForCString. Not for long :-) http://codereview.qt-project.org/14626 > There is also QTextCodec::codecForLocale used by QString::fromLocal8Bit. > > For example, in a french programing team, you would have > label->setText("Résultats Erronés"); > And this will probably be in latin1, because the file is saved as such on > the disc. (and latin1 is faster than utf8). And they'll have to recode their sources to UTF-8 with Qt 5, or add the wrapping QLatin1String. > So if in your library you do > QString foo = file.readAll(); > The result will depends on the application. With Qt 5, it will not. It will be decoded using UTF-8, which is good and bad: Good: because it's well-defined and you know what will happen. Bad: because if you have binary data, UTF-8 cannot decode it. ISO-8859 can decode anything to Unicode, so it's idempotent in a round-trip. UTF-8 isn't, so if you mix QString and QByteArray by mistake, you might cause data corruption. > So the rule is: > - Always be explicit about which encoding you import the string from. > - If it is a literal, use QStringLiteral in 95% of the case, and > QLatin1String in most of th e other cases. We need to document when to use either. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center Intel Sweden AB - Registration Number: 556189-6027 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
