Hi,

besides treating T& and T (which I think is fine for 6.4), anything else should 
probably only be done in 6.5.
I don't currently see much interdependence in the changes you proposed, however 
we should carefully
check that DBus, Qt Remote Objects and QML don't get accidentally broken.

Regarding the string example:

you need something to actually register the string metatype (e.g. calling id or 
qRegisterMetaTypeId)
#include <string>
#include <QDebug>
#include <QMetaType>

Q_DECLARE_METATYPE(std::string) // without this line, the example will still 
not work

int main() {
   qDebug() << QMetaType::fromType<std::string>().name();
   qDebug() << QMetaType::fromName("std::string");
   QMetaType::fromType<std::string>().id();
   qDebug() << QMetaType::fromName("std::string");
}

Only when you register the metatype will it actually be registered under the 
name
"std::string" which is necessary for the name to metatype lookup. If you end up 
with a
std::string parameter in a meta-method of a meta-object, there's a good chance 
that
the registration will happen via QMetaObject::RegisterMethodArgumentMetaType
when it would be needed (assuming that std::string was complete when moc run on
the file containing it).

Fabian

________________________________________
Von: Development <[email protected]> im Auftrag von Volker 
Hilsheimer <[email protected]>
Gesendet: Dienstag, 19. Juli 2022 20:45
An: Macieira, Thiago
Cc: [email protected]
Betreff: Re: [Development] QMetaType and non-const references


> On 19 Jul 2022, at 18:08, Thiago Macieira <[email protected]> wrote:
>
>> Lastly, an aside: Q_DECLARE_METATYPE being effectively unnecessary was the
>> goal for Qt 6, but is not the case yet. I consider that a bug that should
>> finally be fixed in 6.5.
>
> Right. There should be exactly one use for Q_DECLARE_METATYPE: when the name
> you want to register is not the name that the C++ language recognises for your
> type, and this should only be done for legacy reasons.
>
>       typedef QMap<int, int> IntMap;
>       Q_DECLARE_METATYPE(IntMap);
>
> And you may have the string "IntMap" somewhere in your meta objects.

Interestingly,

    qDe0bug() << QMetaType::fromType<std::string>().name();
    qDebug() << QMetaType::fromName("std::string");

prints, with Apple clang:

std::__1::basic_string<char>
QMetaType()

but with msvc 22:

std::basic_string<char,std::char_traits<char>,std::allocator<char>>
QMetaType()

and then "std::string" in your meta object won’t work either, I suppose?

But interestingly, neither does

Q_DECLARE_METATYPE(std::string).

With

qRegisterMetaType<std::string>(“std::string”);

I get

std::__1::basic_string<char>
QMetaType(std::__1::basic_string<char>)

with clang and

td::basic_string<char,std::char_traits<char>,std::allocator<char>>
QMetaType(std::basic_string<char,std::char_traits<char>,std::allocator<char>>)

with msvc 22. What does that mean if e.g. "std::string" is present in a meta 
object?


> Any opinion on what must happen together or not at all?


I agree with Fabian, it seems uncontroversial to treat T& and T as different 
types in the QMetaType system. Code that relies on them being the same needs to 
be fixed anyway. Doing that doesn’t seem to prevent anything else discussed.


Volker

_______________________________________________
Development mailing list
[email protected]
https://lists.qt-project.org/listinfo/development
_______________________________________________
Development mailing list
[email protected]
https://lists.qt-project.org/listinfo/development

Reply via email to