[Development] Metatype system in Qt6

[Olivier Goffart]

On 10/29/18 5:39 PM, Jedrzej Nowacki wrote:
> Hi everyone!
> 
>    While main heat on the mailing list is taken by topic how to encode that we
> are nice, friendly and respectful to each other, I would like to show some
> side project that I had. It is a proposal for base of metatype system for Qt6.
> You can look and comment at it here: https://github.com/nierob/qmetatype. It
> is quite fresh and it was rather a storage for functionality ideas. I haven't
> tried to compare performance of it to the current system, but for sure it has
> more flexibility and I believe, that conceptually it could serve us during
> Qt6. Anyway before spending too much time on it I would like to get some early
> feedback and questions.

The discussion in that other thread are not finished, so please wait until 
there is consensus before being nice!

But thanks for caring about the QMetaType system.
I had a short look. I think it would be usefull if you already used names 
closer to what they are supposed to be. Namespace N, P, are not so nice names.

The idea of using a single function with operation is quite a good idea I like 
it. As long as the function takes the typeid as a parameter.
Indeed, I'm thinking about dynamic types that would come from language 
bindings: in this situation, while it is easy to allocate memory on the heap, 
it is not easy to create a new function pointer for every dynamic type that we 
would register.

Regarding the extension, i don't know if it is such a good idea, because you 
never know what you can rely on.
say you have a QVariant with some type that comes from some part of your code, 
how do you know if you can print it with qDebug, or convert it to string, how 
do you register that?
IMHO, there should not be extensions! All operation that we want to make 
available for a type should be always available. Using SFINAE to find out if it 
is available.

So what are the operation we want on a QMetaType:

- for QVariant, and the queued connections: copy / destruction.  Ideally in 
place. So we also need the size/alignement to be able to allocate the memory

- for qDebug, we need the QDebug operator <<

- for QDataStream, we need the operator << and >>, and an unique identifier 
that stay the same. Currently, this is the type id for builtin types, and the 
name for custom type. I suggest we use the name, if we want to keep 
compatibility with old steam, we will need to keep a mapping from old type id, 
to new name.

As for the name, we can indeed find a way to extract it from parsing it from 
__PRETTY_FUNC__ as you do. It would work on every compiler we support i guess, 
but we need spcial code for that as it is not really standard.
In Qt5, we also need the name for the string-based connection syntax. However, 
I believe we can do that without relying on the name "as-seen-by-moc", if the 
moc generated code always register the types. (this is already almost the case)

- What about  QSequentialIterable / QAssociativeIterable? We also need 
something there.


In the design document you say:

 > The whole registry is kept behind a mutex and it is very central, the mutex
 > usage actually shows on profilers.

This used to be the case before Qt 5.7, but since then, QReadWriteMutex was 
greatly optimized, does it still show in the profiler?

You will need that anyway, because relying on a static variable in a function 
template does not work on MSVC as far as i know. (Last time i tried was a long 
time ago, and they had different address and value in different libraries)
That's why we will probably need to initialize it with a name lookup.

It is probably still a good idea to register builtin type at compile time, 
since we want to save in registering time. There are some data structures out 
there with compile time hash table that can be extended at runtime.


So the early feedback i can give on your code is that it is a bit more 
complicated than necessary with the extension. and i think it can be simplified.

-- 
Olivier

Woboq - Qt services and support - https://woboq.com - https://code.woboq.org