> On 19 Jul 2022, at 21:34, Fabian Kosmale <fabian.kosm...@qt.io> wrote:
>
> 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).
Ok, so QMetaType::name() will not necessarily return the name that was used in
QMetaType::fromName, and the name returned might be compiler and C++ library
specific.
That is good to know and should perhaps be mentioned in the documentation. It
means that QMetaType objects cannot be serialized, I suppose.
Volker
> ________________________________________
> Von: Development <development-boun...@qt-project.org> im Auftrag von Volker
> Hilsheimer <volker.hilshei...@qt.io>
> Gesendet: Dienstag, 19. Juli 2022 20:45
> An: Macieira, Thiago
> Cc: development@qt-project.org
> Betreff: Re: [Development] QMetaType and non-const references
>
>
>> On 19 Jul 2022, at 18:08, Thiago Macieira <thiago.macie...@intel.com> 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
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
_______________________________________________
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
