Re: [Development] Applications using -fno-rtti
On 21/06/20 19:13, Thiago Macieira wrote: > A set of patches were dropped from the middle of the series, implementing the > vfork I mentioned. So the patch needs to be rebased and adjusted. Other than > that, it's fine. Let's try: https://codereview.qt-project.org/c/qt/qtbase/+/305791/1 Ciao, Alberto -- http://www.mardy.it - Geek in un lingua international ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Applications using -fno-rtti
On Monday, 22 June 2020 00:22:33 PDT Eike Ziller wrote: > dynamic_cast would be most useful if you could avoid using Q_OBJECT (and > deriving from QObject) just for the purpose of casting. If you use Q_OBJECT > throughout your class hierarchy, qobject_cast is available anyhow. So, the > argument that Q_OBJECT makes it safe to use dynamic_cast reads a bit > strange. It's a circular argument: Q_OBJECT makes for a safe cast because it does the thing that makes cast safe. But if you can do the right thing, then you don't need Q_OBJECT. Admittedly, it's easier to get Q_OBJECT right, because of the need for moc. Running moc on another library's headers is a big indication that something is wrong. But I've seen it. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Applications using -fno-rtti
> On Jun 22, 2020, at 01:18, Thiago Macieira wrote: > > On Sunday, 21 June 2020 06:44:23 PDT André Pönitz wrote: >> I would appreciate if someone on Windows could run a reality check on that >> with a dynamic_cast between classes that don't have a key function, i.e. >> where everything is inlined and/or templates. > > They must have a key virtual function. But that's not too much to ask, since > Q_OBJECT is already doing that. dynamic_cast would be most useful if you could avoid using Q_OBJECT (and deriving from QObject) just for the purpose of casting. If you use Q_OBJECT throughout your class hierarchy, qobject_cast is available anyhow. So, the argument that Q_OBJECT makes it safe to use dynamic_cast reads a bit strange. Br, Eike -- Eike Ziller Principal Software Engineer The Qt Company GmbH Erich-Thilo-Straße 10 D-12489 Berlin eike.zil...@qt.io http://qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Applications using -fno-rtti
Il 21/06/20 13:22, Lars Knoll ha scritto: We are making use of dynamic_cast and typeid in Qt nowadays, so I guess it’s high time we adjust the wiki. In the light of this: has anyone thought of deprecating in Qt 6 the ad-hoc casting functions like qgraphicsitem_cast, qstyleoption_cast and so on? (*NOT* qobject_cast) My 2 c, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: Firma crittografica S/MIME ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Applications using -fno-rtti
On Sunday, 21 June 2020 06:44:23 PDT André Pönitz wrote: > I would appreciate if someone on Windows could run a reality check on that > with a dynamic_cast between classes that don't have a key function, i.e. > where everything is inlined and/or templates. They must have a key virtual function. But that's not too much to ask, since Q_OBJECT is already doing that. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Applications using -fno-rtti
On Sun, Jun 21, 2020 at 11:22:58AM +, Lars Knoll wrote: > We didn’t want it in earlier versions of Qt for mainly two reasons. Early > implementations had quite an overhead on library size, and dynamic_cast didn’t > work reliable between DLL boundaries on Windows. Both problems have gone away > many years ago. I would appreciate if someone on Windows could run a reality check on that with a dynamic_cast between classes that don't have a key function, i.e. where everything is inlined and/or templates. > [...] > We are making use of dynamic_cast and typeid in Qt nowadays, so I guess it’s > high time we adjust the wiki. The fact that it works in some, even common, situations doesn't imply it works safely everywhere. Andre' ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Applications using -fno-rtti
On Sunday, 21 June 2020 05:35:20 PDT Konstantin Ritt wrote: > I, for example, didn't know the issue with dynamic_cast across dll > boundaries is not an issue anymore. It's never been. What changed is our understanding of how to make it work across DLL boundaries. The answer is: ALL classes with virtuals must be exported and must have one non-inline virtual member. This includes templates. Corollary: templates with virtual should be avoided at all costs. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Applications using -fno-rtti
On Sunday, 21 June 2020 08:22:14 PDT Alberto Mardegan wrote:
> On 20/06/20 23:45, Thiago Macieira wrote:
> > No, because it won't catch this:
> >
> > class MyProcess : QProcess
> > {
> > protected:
> > virtual void setupChildProcess();
> > };
> >
> > Note the lack of Q_OBJECT.
>
> But what is the harm if we don't catch that? It's still better than a
> crash, isn't it?
No, a crash is better than silent data corruption. I'm glad you had a hard
error that allowed us to detect the problem.
The idea of the check was so enable vfork() semantics before calling that
function above. If we don't know it's safe to call it, you could cause silent
data corruption. Now, the part of the vfork was rolled back because it
couldn't work, so the worst that could happen now is a deadlock, which means
the problem might be intermittent. A hard crash is still better.
> > But a variant of https://codereview.qt-project.org/c/qt/qtbase/+/292540
> > might be acceptable. It would replace the typeid() check with the GCC
> > extension, which will work for all GCC-based builds, which is the
> > totality of Linux distributions.
>
> If that is your preferred solution, I'm fine with that too. But is there
> something wron gwith that patch, or can it be applied as is?
A set of patches were dropped from the middle of the series, implementing the
vfork I mentioned. So the patch needs to be rebased and adjusted. Other than
that, it's fine.
> > By the way, can you say what you needed to derive from QProcess for? If it
> > was to override setupChildProcess() like in the example above, what are
> > you doing in the function?
>
> No, that code is not overriding any virtual methods, it's just extending
> the class.
Thanks.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel System Software Products
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] Applications using -fno-rtti
On 20/06/20 23:45, Thiago Macieira wrote:
> No, because it won't catch this:
>
> class MyProcess : QProcess
> {
> protected:
> virtual void setupChildProcess();
> };
>
> Note the lack of Q_OBJECT.
But what is the harm if we don't catch that? It's still better than a
crash, isn't it?
Also, the documentation of QObject says (talking about Q_OBJECT):
"We strongly recommend the use of this macro in all subclasses of
QObject regardless of whether or not they actually use signals, slots
and properties, since failure to do so may lead certain functions to
exhibit strange behavior."
I guess we could then use a solution based on QMetaObject, and let the
missing Q_OBJECT cases "exhibit strange behavior"?
> But a variant of https://codereview.qt-project.org/c/qt/qtbase/+/292540 might
> be acceptable. It would replace the typeid() check with the GCC extension,
> which will work for all GCC-based builds, which is the totality of Linux
> distributions.
If that is your preferred solution, I'm fine with that too. But is there
something wron gwith that patch, or can it be applied as is?
> By the way, can you say what you needed to derive from QProcess for? If it
> was
> to override setupChildProcess() like in the example above, what are you doing
> in the function?
No, that code is not overriding any virtual methods, it's just extending
the class.
Ciao,
Alberto
--
http://www.mardy.it - Geek in un lingua international
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] Applications using -fno-rtti
Den sön 21 juni 2020 kl 14:37 skrev Konstantin Ritt : > > > I think we then had discussions when moving from Qt 4 to Qt 5, that we will > > start requiring RTTI. > > However this was never promoted, and now you're saying people who ported > their projects with no-rtti to Qt5 had to enable rtti years ago or expect > crashes?) > > Thanks to Alberto for pointing this issue now, when the majority didn't > switch to the new LTS yet. > I, for example, didn't know the issue with dynamic_cast across dll boundaries > is not an issue anymore. > > Plz make sure the documentation is up to date and `CONFIG += rtti_off` does > nothing as of 5.15. Don't touch CONFIG += rtti_off, since QMake can be used for non-Qt projects, who may want the ability to toggle this. Agree the docs should be updated, and it should have been more clearly communicated. The -no-rtti configure switch for Qt itself was removed with https://codereview.qt-project.org/c/qt/qtbase/+/182660 (since Qt 5.8). Elvis > > Regards, > Konstantin > > > вс, 21 июн. 2020 г. в 14:23, Lars Knoll : >> >> >> >> > On 21 Jun 2020, at 13:10, Giuseppe D'Angelo via Development >> > wrote: >> > >> > Il 20/06/20 22:45, Thiago Macieira ha scritto: >> >> On Saturday, 20 June 2020 11:31:25 PDT Alberto Mardegan wrote: >> >>> I think I missed an announcement about Qt applications having to use >> >>> RTTI; on the opposite, I thought that the whole point of QMetaObject was >> >>> not to require RTTI support; has this changed? >> >> As you can see from the commit, no provision was made for no-RTTI builds. >> >> I >> >> don't think they've ben allowed since 5.0. >> > >> > The Qt coding policy document still says that no RTTI facilities are >> > allowed within Qt: >> > >> >> https://wiki.qt.io/Coding_Conventions >> > >> > (Unchanged since 2015; before, I'm sure that document was somewhere else, >> > with the same contents regarding this matter.) >> > >> > Where/when was such a change of policy decided? >> >> We didn’t want it in earlier versions of Qt for mainly two reasons. Early >> implementations had quite an overhead on library size, and dynamic_cast >> didn’t work reliable between DLL boundaries on Windows. Both problems have >> gone away many years ago. >> >> I have to go by what I remember now, but I think we then had discussions >> when moving from Qt 4 to Qt 5, that we will start requiring RTTI. The >> reasons where that dynamic_cast<> and typeid require it and it has very >> little overhead on library size (as opposed to exceptions which are still >> optional). By that time (or maybe even earlier), we also started compiling >> Qt with RTTI enabled on all platforms. >> >> But it looks like nobody ever adjusted the wiki page :/ >> >> We are making use of dynamic_cast and typeid in Qt nowadays, so I guess it’s >> high time we adjust the wiki. >> >> Cheers, >> Lars >> >> ___ >> 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 ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Applications using -fno-rtti
> I think we then had discussions when moving from Qt 4 to Qt 5, that we will start requiring RTTI. However this was never promoted, and now you're saying people who ported their projects with no-rtti to Qt5 had to enable rtti years ago or expect crashes?) Thanks to Alberto for pointing this issue now, when the majority didn't switch to the new LTS yet. I, for example, didn't know the issue with dynamic_cast across dll boundaries is not an issue anymore. Plz make sure the documentation is up to date and `CONFIG += rtti_off` does nothing as of 5.15. Regards, Konstantin вс, 21 июн. 2020 г. в 14:23, Lars Knoll : > > > > On 21 Jun 2020, at 13:10, Giuseppe D'Angelo via Development < > development@qt-project.org> wrote: > > > > Il 20/06/20 22:45, Thiago Macieira ha scritto: > >> On Saturday, 20 June 2020 11:31:25 PDT Alberto Mardegan wrote: > >>> I think I missed an announcement about Qt applications having to use > >>> RTTI; on the opposite, I thought that the whole point of QMetaObject > was > >>> not to require RTTI support; has this changed? > >> As you can see from the commit, no provision was made for no-RTTI > builds. I > >> don't think they've ben allowed since 5.0. > > > > The Qt coding policy document still says that no RTTI facilities are > allowed within Qt: > > > >> https://wiki.qt.io/Coding_Conventions > > > > (Unchanged since 2015; before, I'm sure that document was somewhere > else, with the same contents regarding this matter.) > > > > Where/when was such a change of policy decided? > > We didn’t want it in earlier versions of Qt for mainly two reasons. Early > implementations had quite an overhead on library size, and dynamic_cast > didn’t work reliable between DLL boundaries on Windows. Both problems have > gone away many years ago. > > I have to go by what I remember now, but I think we then had discussions > when moving from Qt 4 to Qt 5, that we will start requiring RTTI. The > reasons where that dynamic_cast<> and typeid require it and it has very > little overhead on library size (as opposed to exceptions which are still > optional). By that time (or maybe even earlier), we also started compiling > Qt with RTTI enabled on all platforms. > > But it looks like nobody ever adjusted the wiki page :/ > > We are making use of dynamic_cast and typeid in Qt nowadays, so I guess > it’s high time we adjust the wiki. > > Cheers, > Lars > > ___ > 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
Re: [Development] Applications using -fno-rtti
> On 21 Jun 2020, at 13:10, Giuseppe D'Angelo via Development > wrote: > > Il 20/06/20 22:45, Thiago Macieira ha scritto: >> On Saturday, 20 June 2020 11:31:25 PDT Alberto Mardegan wrote: >>> I think I missed an announcement about Qt applications having to use >>> RTTI; on the opposite, I thought that the whole point of QMetaObject was >>> not to require RTTI support; has this changed? >> As you can see from the commit, no provision was made for no-RTTI builds. I >> don't think they've ben allowed since 5.0. > > The Qt coding policy document still says that no RTTI facilities are allowed > within Qt: > >> https://wiki.qt.io/Coding_Conventions > > (Unchanged since 2015; before, I'm sure that document was somewhere else, > with the same contents regarding this matter.) > > Where/when was such a change of policy decided? We didn’t want it in earlier versions of Qt for mainly two reasons. Early implementations had quite an overhead on library size, and dynamic_cast didn’t work reliable between DLL boundaries on Windows. Both problems have gone away many years ago. I have to go by what I remember now, but I think we then had discussions when moving from Qt 4 to Qt 5, that we will start requiring RTTI. The reasons where that dynamic_cast<> and typeid require it and it has very little overhead on library size (as opposed to exceptions which are still optional). By that time (or maybe even earlier), we also started compiling Qt with RTTI enabled on all platforms. But it looks like nobody ever adjusted the wiki page :/ We are making use of dynamic_cast and typeid in Qt nowadays, so I guess it’s high time we adjust the wiki. Cheers, Lars ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Applications using -fno-rtti
Il 20/06/20 22:45, Thiago Macieira ha scritto: On Saturday, 20 June 2020 11:31:25 PDT Alberto Mardegan wrote: I think I missed an announcement about Qt applications having to use RTTI; on the opposite, I thought that the whole point of QMetaObject was not to require RTTI support; has this changed? As you can see from the commit, no provision was made for no-RTTI builds. I don't think they've ben allowed since 5.0. The Qt coding policy document still says that no RTTI facilities are allowed within Qt: https://wiki.qt.io/Coding_Conventions (Unchanged since 2015; before, I'm sure that document was somewhere else, with the same contents regarding this matter.) Where/when was such a change of policy decided? Thanks, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: Firma crittografica S/MIME ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Applications using -fno-rtti
20.06.2020, 23:49, "Thiago Macieira" : > On Saturday, 20 June 2020 11:31:25 PDT Alberto Mardegan wrote: >> I think I missed an announcement about Qt applications having to use >> RTTI; on the opposite, I thought that the whole point of QMetaObject was >> not to require RTTI support; has this changed? > > As you can see from the commit, no provision was made for no-RTTI builds. I > don't think they've ben allowed since 5.0. > > No-exceptions is still allowed. No-RTTI is not. So, any Qt code is allowed crash if user code is compiled with disabled RTTI? Wonderful. -- Regards, Konstantin ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Applications using -fno-rtti
On Saturday, 20 June 2020 11:31:25 PDT Alberto Mardegan wrote:
> I think I missed an announcement about Qt applications having to use
> RTTI; on the opposite, I thought that the whole point of QMetaObject was
> not to require RTTI support; has this changed?
As you can see from the commit, no provision was made for no-RTTI builds. I
don't think they've ben allowed since 5.0.
No-exceptions is still allowed. No-RTTI is not.
> Anyway, were I to submit a patch replacing typeid() with something which
> does not require RTTI ("q->metaObject() == QProcess::staticMetaObject()"
> would work, I guess? Or maybe even comparing q->className()?), would
> that be accepted?
No, because it won't catch this:
class MyProcess : QProcess
{
protected:
virtual void setupChildProcess();
};
Note the lack of Q_OBJECT.
But a variant of https://codereview.qt-project.org/c/qt/qtbase/+/292540 might
be acceptable. It would replace the typeid() check with the GCC extension,
which will work for all GCC-based builds, which is the totality of Linux
distributions.
By the way, can you say what you needed to derive from QProcess for? If it was
to override setupChildProcess() like in the example above, what are you doing
in the function?
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel System Software Products
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] Applications using -fno-rtti
On 20/06/20 21:42, Konstantin Tokarev wrote:
> Comparing metaObject() with staticMetaObject() is wrong because it would fail
> even for QProcess.
No, I tried, it seems to work as expected:
==
#include
#include
class BaseClass: public QObject {
Q_OBJECT
};
class DerivedClass: public BaseClass {
Q_OBJECT
};
class TypeCompare: public QObject {
Q_OBJECT
private Q_SLOTS:
void testType() {
BaseClass base;
DerivedClass derived;
QCOMPARE(base.metaObject(), ::staticMetaObject);
QCOMPARE(derived.metaObject(), ::staticMetaObject);
// this fails
QCOMPARE(derived.metaObject(), ::staticMetaObject);
}
};
QTEST_GUILESS_MAIN(TypeCompare)
#include "tst_type_compare.moc"
==
--
http://www.mardy.it - Geek in un lingua international
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] Applications using -fno-rtti
Il 20/06/20 21:31, Alberto Mardegan ha scritto: Sorry, my wording was imprecise: we want to know if q is a*proper* subclass of QProcess (that is, a derived class). Note that inherits() / className() will not work as intended if the subclass does not use Q_OBJECT. Only typeid() will tell you the truth in that case. If you don't care about this use case, then ignore this issue :) HTH, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: Firma crittografica S/MIME ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Applications using -fno-rtti
On 20/06/20 22:21, Alexey Minnekhanov wrote: > > сб, 20 июн. 2020 г. в 22:01, Alberto Mardegan > mailto:ma...@users.sourceforge.net>>: > > we only want to know if we are a subclass of QProcess. > > QObject::inherits(..) ? Sorry, my wording was imprecise: we want to know if q is a *proper* subclass of QProcess (that is, a derived class). Ciao, Alberto -- http://www.mardy.it - Geek in un lingua international ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Applications using -fno-rtti
20.06.2020, 22:12, "Allan Sandfeld Jensen" : > On Samstag, 20. Juni 2020 21:00:27 CEST Alberto Mardegan wrote: >> On 20/06/20 21:42, Konstantin Tokarev wrote: >> > Comparing metaObject() with staticMetaObject() is wrong because it would >> > fail even for QProcess. >> >> I didn't try, but why would it fail? >> >> > OTOH, using qobject_cast would handle classes derived >> > from QProcess correctly, unlike code with typeid(). >> >> But how would you use qobject_cast in this case? We don't know what >> class to cast to; we only want to know if we are a subclass of QProcess. > > Can't you just check if a cast to QProcess succedes or fails then? > Sorry, I haven't read the context carefully. In this particular case it's known that q is always instance of QProcess or derived class, and subject code distinguishes QProcess base class from derivatives. In this case, qobject_cast is not appropriate and it seems like comapring className() is a way to go. -- Regards, Konstantin ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Applications using -fno-rtti
сб, 20 июн. 2020 г. в 22:01, Alberto Mardegan : > we only want to know if we are a subclass of QProcess. > QObject::inherits(..) ? ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Applications using -fno-rtti
On Samstag, 20. Juni 2020 21:00:27 CEST Alberto Mardegan wrote: > On 20/06/20 21:42, Konstantin Tokarev wrote: > > Comparing metaObject() with staticMetaObject() is wrong because it would > > fail even for QProcess. > > I didn't try, but why would it fail? > > > OTOH, using qobject_cast would handle classes derived > > from QProcess correctly, unlike code with typeid(). > > But how would you use qobject_cast in this case? We don't know what > class to cast to; we only want to know if we are a subclass of QProcess. > Can't you just check if a cast to QProcess succedes or fails then? ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Applications using -fno-rtti
On 20/06/20 21:42, Konstantin Tokarev wrote: > Comparing metaObject() with staticMetaObject() is wrong because it would fail > even for QProcess. I didn't try, but why would it fail? > OTOH, using qobject_cast would handle classes derived > from QProcess correctly, unlike code with typeid(). But how would you use qobject_cast in this case? We don't know what class to cast to; we only want to know if we are a subclass of QProcess. Ciao, Alberto -- http://www.mardy.it - Geek in un lingua international ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Applications using -fno-rtti
20.06.2020, 21:34, "Alberto Mardegan" :
> Hi all!
> A couple of days ago a bug was filed against a project of mine, which
> has been built with -fno-rtti since Qt4 times:
>
> https://bugzilla.opensuse.org/show_bug.cgi?id=1172904
>
> The bug, it appears, is a crash in QProcess due to the use of typeid(),
> which was introduced in Qt 5.15:
>
> https://code.qt.io/cgit/qt/qtbase.git/commit/?h=5.15=97645478de3ceffce11f58eab140c4c775e48be5
>
> I think I missed an announcement about Qt applications having to use
> RTTI; on the opposite, I thought that the whole point of QMetaObject was
> not to require RTTI support; has this changed?
>
> Anyway, were I to submit a patch replacing typeid() with something which
> does not require RTTI ("q->metaObject() == QProcess::staticMetaObject()"
> would work, I guess? Or maybe even comparing q->className()?), would
> that be accepted?
I think it should use qobject_cast.
Comparing metaObject() with staticMetaObject() is wrong because it would fail
even for QProcess. OTOH, using qobject_cast would handle classes derived
from QProcess correctly, unlike code with typeid().
--
Regards,
Konstantin
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
[Development] Applications using -fno-rtti
Hi all!
A couple of days ago a bug was filed against a project of mine, which
has been built with -fno-rtti since Qt4 times:
https://bugzilla.opensuse.org/show_bug.cgi?id=1172904
The bug, it appears, is a crash in QProcess due to the use of typeid(),
which was introduced in Qt 5.15:
https://code.qt.io/cgit/qt/qtbase.git/commit/?h=5.15=97645478de3ceffce11f58eab140c4c775e48be5
I think I missed an announcement about Qt applications having to use
RTTI; on the opposite, I thought that the whole point of QMetaObject was
not to require RTTI support; has this changed?
Anyway, were I to submit a patch replacing typeid() with something which
does not require RTTI ("q->metaObject() == QProcess::staticMetaObject()"
would work, I guess? Or maybe even comparing q->className()?), would
that be accepted?
Ciao,
Alberto
--
http://www.mardy.it - Geek in un lingua international
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
