> On 19 Jul 2022, at 21:34, Fabian Kosmale <[email protected]> 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 <[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
