On Friday, 30 de September de 2011 14:54:32 André Pönitz wrote: > On Friday 30 September 2011 14:11:33 ext Olivier Goffart wrote: > > Another thing that need to be taken in account is that QStringLiteral > > takes > > more memory in the binary. > > Actually quite a few of the string literals we have in Creator are > essentially plain ASCII "identifiers" that are only converted to QStrings > to be able to interface QVariantMap, QSettings etc. > > I have this nagging gut feeling that it would be better for performance if > these would take QByteArray keys instead. If someone has the desparate wish > to use more than 7 bits for his key strings (I certainly don't), the > convention could just be that the encoding is implicitly assumed to be > UTF-8. > > I understand that this is (a) not possible to change, and (b) would mean > falling back to the Dark Ages of std::string-with-uncertain-encoding, but > still, we are discussing making a conversion fast that could be avoided > altogether in a lot of cases by just having another API.
For an application's internal data, if all it wants is to store 7-bit keys to
variants, it can simply use
QMap<QByteArray, QVariant>
It doesn't have to use QVariantMap. That's what std::basic_string does: if you
want to use something other than char, you can (hence, std::wstring).
However, asking QSettings to have a QByteArray API is asking too much in my
opinion. That would mean either implicit conversions anyway into the internal
storage type, or increasing the complexity of every function dealing with the
multiple types of keys.
Neither option is interesting. Increasing the complexity of code means we may
have lingering bugs for years due to less-tested codepaths, missing fixes that
go to one branch but not the other, etc. It also means increased library size,
increased runtime due to the extra checks when compared to the library taking
one single type.
The implicit conversions just hide the problem. Instead of doing the right
thing and using QStringLiteral or caching your QStrings, you might be deceived
into writing bad code.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Qt5-feedback mailing list [email protected] http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
