QHash<int,QString> vs QHash<int,QByteArray>
-
I am creating a simple string lookup and index the lookup using an enum (int). I noticed that the roleNames method of QAbstractListModel uses QHash<int,QByteArray> for its return value. I am not using my lookup for this purpose, but I was wondering if there are technical reasons to favor QHash<int,QByteArray> over QHash<int,QString> for a lookup table. I understand QString may interpret a string constant differently than QByteArray, but I am using the output in a QString anyway. So at some point it will get converted.
So, are there any technical advantages of using QHash<int,QString> or QHash<int,QByteArray>? I cannot identify any, but that doesn't mean there aren't any.
-
It depends on what you need - do you need a QString or is it enough to use a QByteArray.
Qt Online Installer direct download: https://download.qt.io/official_releases/online_installers/
Visit the Qt Academy at https://academy.qt.io/catalog -
It depends on what you need - do you need a QString or is it enough to use a QByteArray.
@Christian-Ehrlicher At this point I don't really care. It works, that is what I need. Thanks.
-
I am creating a simple string lookup and index the lookup using an enum (int). I noticed that the roleNames method of QAbstractListModel uses QHash<int,QByteArray> for its return value. I am not using my lookup for this purpose, but I was wondering if there are technical reasons to favor QHash<int,QByteArray> over QHash<int,QString> for a lookup table. I understand QString may interpret a string constant differently than QByteArray, but I am using the output in a QString anyway. So at some point it will get converted.
So, are there any technical advantages of using QHash<int,QString> or QHash<int,QByteArray>? I cannot identify any, but that doesn't mean there aren't any.
@fcarney said in QHash<int,QString> vs QHash<int,QByteArray>:
So, are there any technical advantages of using QHash<int,QString> or QHash<int,QByteArray>?
I can't think of any technical advantages.
For QHash<int,QString> vs. QHash<int,QByteArray>, the hashing and lookup complexity is the same because the keys (
int) are the same.Technically, the difference between QString and QByteArray should be negligible. It is a bit cheaper computationally to deal with QByteArray than QString for ASCII text, but converting QByteArray to QString comes with some overhead.
Philosophically, I thinkIgnore me; as @Kent-Dorfman pointed out below,roleNames()should have been implemented using QString because names are text strings. A byte array is not ideal for representing text in a globalised era.roleNames()stores human-readable "code", not text.I am using the output in a QString anyway.
Then you might as well store your data as QHash<int, QString>.
-
I think the reason the list model uses QByteArray is that it is just raw data, where using <int, QString> would be more restrictive to the progrmmer because of the implicit conversion of QString...which may be undesirable for some. QByteArray is trivially converted to other types or a pointer to some other type.
I light my way forward with the fires of all the bridges I've burned behind me.
-
I think the reason the list model uses QByteArray is that it is just raw data, where using <int, QString> would be more restrictive to the progrmmer because of the implicit conversion of QString...which may be undesirable for some. QByteArray is trivially converted to other types or a pointer to some other type.
@Kent-Dorfman said in QHash<int,QString> vs QHash<int,QByteArray>:
I think the reason the list model uses QByteArray is that it is just raw data.... QByteArray is trivially converted to other types or a pointer to some other type.
QAbstractItemModel::roleNames()deals with names (strings), not raw data. -
but that wasn't his question, which I took to ask "why" a utility function key/value pair uses QByteArray instead of a class specialization such as QString. It's about remaining generic at the utility level. QString is a more restrictive value type in key/value pairs than than the flexibility you get with a value type of QByteArray.
Where would those roleNames commonly be used? Since they are themselves a type of code metadata (possibly used internally by the Qt framework), I don't think you'd want any QString locale conversion done on them.
I light my way forward with the fires of all the bridges I've burned behind me.
-
but that wasn't his question, which I took to ask "why" a utility function key/value pair uses QByteArray instead of a class specialization such as QString. It's about remaining generic at the utility level. QString is a more restrictive value type in key/value pairs than than the flexibility you get with a value type of QByteArray.
Where would those roleNames commonly be used? Since they are themselves a type of code metadata (possibly used internally by the Qt framework), I don't think you'd want any QString locale conversion done on them.
@Kent-Dorfman said in QHash<int,QString> vs QHash<int,QByteArray>:
but that wasn't his question, which I took to ask "why" a utility function key/value pair uses QByteArray instead of a class specialization such as QString.
Ah, you're right! My bad.
I've updated my reply above.
@Kent-Dorfman said in QHash<int,QString> vs QHash<int,QByteArray>:
Where would those roleNames commonly be used? Since they are themselves a type of code metadata (possibly used internally by the Qt framework), I don't think you'd want any QString locale conversion done on them.
Right again. It's the same as QMetaObject/QMetaMethod storing names as QByteArray and const char* instead of QString.
-
but that wasn't his question, which I took to ask "why" a utility function key/value pair uses QByteArray instead of a class specialization such as QString. It's about remaining generic at the utility level. QString is a more restrictive value type in key/value pairs than than the flexibility you get with a value type of QByteArray.
Where would those roleNames commonly be used? Since they are themselves a type of code metadata (possibly used internally by the Qt framework), I don't think you'd want any QString locale conversion done on them.
@Kent-Dorfman said in QHash<int,QString> vs QHash<int,QByteArray>:
Where would those roleNames commonly be used? Since they are themselves a type of code metadata (possibly used internally by the Qt framework), I don't think you'd want any QString locale conversion done on them.
Also, for ASCII-only strings QString takes twice as much memory than QByteArray because of UTF16 encoding.
