QVariant does not support int8 and int16

[DerHandwerk]

Hi,

recently I discovered some difficulties with QVariant holding 8 and 16 bit integers.

Example:
@
const QVariant a ((qint8)1);
const QVariant b ((qint16)1);
const QVariant c ((qint32)1);

qDebug() << a.type() << b.type() << c.type();
// output: QVariant::int QVariant::int QVariant::int
@

As shown above I am losing the type informations for 8 and 16 bit integers since they are both mapped int 32 bit integer. After reading the documentation I found out that there are no overloaded constructors for these values and so they are implicitly mapped to 32 bit integer.

Is there any good reason why they are missing?

Greetings DerHandwerk

[sierdzio]

Yes. They are not needed in 99% of cases ;) But you can register them as custom types for QVariant and it should work.

[DerHandwerk]

Thanks for your answer, but wouldn't it be a nice addition to QVariant to support all native primitive c++ types?

[John.Curious]

Yes, it would make sense to me too. I guess, QT developers wish to keep the number of registered types to the minimum. I have recently discovered that they do linear search through a flat table of defined metatypes when one looks up a type by name.

sierdzio, you seems to be a senior person in QT, do you think it would make more sense to use Hash or Map when a type needs to be searched by name?

[DerHandwerk]

I am curious if this could be a feature in a future Qt release :-D.

[sierdzio]

For small sets, Map is faster. For large sets Hash is a better choice, as it gives flat search time. You can search the web for QMap and QHash lookup benchmarks.

DerHandwerk those kinds of questions should be asked on development mailing lists or posted as a feature request on Jira. Very few Qt developers are active on this forum. If you want to know my opinion: since they have not been added in all those years QVariant has existed, it's unlikely people will be willing to add them now. You would need prepare some serious arguments to back your request.

[John.Curious]

I was not comparing Map vs Hash, I was talking about the developers using linear search through the flat table instead of using either map or hash. What they are doing is much less efficient than both map and hash.

You are right, developers might not be willing to change anything since there are not too many complains. That is why I wished to see a response to such an issue here before bothering the developers.

I guess people do not look up meta objects by names too frequently, otherwise somebody would already submit a suggestion. Neither meta-objects are probably used much outside of QT internal stuff. However, I would personally need that for what I am doing, and I may need to add hash or map look up on my own redundant table.

It looks like the meta-object framework was developed to serve a small set of objects, and it apparently covers QT's needs well enough so far. Little activity on this thread shows it too. I will probably not bother the developers with a suggestion, unless you think I should.

[sierdzio]

OK, sorry then, I have misunderstood you. I do not know the rationale behind current implementation, but it is indeed likely that it's mostly historical and nobody felt the need to touch it because "it works".

Meta Object system lies at the heart of Qt Quick and Signals and Slots system, so it's mighty important that it is as efficient as possible. Therefore I think you may try talking to the more hardcore Qt devs.