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
