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,
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
> 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
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 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.
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
>
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
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
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,
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
> 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
> 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
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
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
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
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
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
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*
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
сб, 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
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
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().
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
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:
24 matches
Mail list logo
