On Fri, Mar 15, 2024 at 10:48 PM Marc Mutz via Development <
development@qt-project.org> wrote:
> The member variable thing sounds very wrong. I'd be surprised if it
> compiled.
Then you'd be surprised.
> If it does, it's probably something new in C++23 or 26 whereby
> you can use `using` for
On 15.03.24 21:21, Jaroslaw Kobus via Development wrote:
[...]
> Just found some reasoning, though not sure how much valid it is:
> https://www.learncpp.com/cpp-tutorial/hiding-inherited-functionality/
>
> Probably there are more resources about this topic in the internet.
That page doesn't look
> From: Development on behalf of Giuseppe
> D'Angelo via Development
> Sent: Friday, March 15, 2024 8:58 PM
> To: development@qt-project.org
> Subject: Re: [Development] Should QObject::event() be protected or public?
>
> Il 15/03/24 19:22, Giuseppe D'Angelo via Development ha scritto:
>> Il
Il 15/03/24 19:22, Giuseppe D'Angelo via Development ha scritto:
Il 15/03/24 19:17, Jaroslaw Kobus via Development ha scritto:
+1. Typically, the designer of a subclass knows what he is doing. But it
also happens that users of this class know better how to use it :)
I'm not sure what this
On 15/3/24 19:57, Jean-Michaël Celerier wrote:
There's nothing more frustrating that instantiating a C++ type on the stack
like
MyType foo;
and having to call a function with:
static_cast(foo).someVirtualMethod();
Or:
foo.Base::someVirtualMethod();
[..]
--
Ahmad Samir
Il 15/03/24 19:17, Jaroslaw Kobus via Development ha scritto:
+1. Typically, the designer of a subclass knows what he is doing. But it
also happens that users of this class know better how to use it :)
I'm not sure what this means.
If you override `event()` (public in QObject) as e.g.
> From: Development on behalf of Thiago
> Macieira
> Sent: Friday, March 15, 2024 7:03 PM
> To: development@qt-project.org
> Subject: Re: [Development] Should QObject::event() be protected or public?
>
> On Friday, 15 March 2024 10:09:31 PDT Marc Mutz via Development wrote:
>> I like simple
On Friday, 15 March 2024 11:03:19 PDT Thiago Macieira wrote:
> On Friday, 15 March 2024 10:09:31 PDT Marc Mutz via Development wrote:
> > I like simple rules. "Overrides should have the same access level as the
> > initial virtual function." is a simple rule.
>
> Amend that to "... unless there's
On Friday, 15 March 2024 10:09:31 PDT Marc Mutz via Development wrote:
> I like simple rules. "Overrides should have the same access level as the
> initial virtual function." is a simple rule.
Amend that to "... unless there's an explicit reason not to". With that, I'm
ok. As you can still
There's nothing more frustrating that instantiating a C++ type on the stack
like
MyType foo;
and having to call a function with:
static_cast(foo).someVirtualMethod();
because "The base class is the interface" and all the
overriding methods are marked private.
This is just adding
On 15.03.24 18:31, Christian Kandeler via Development wrote:
> On 3/15/24 18:09, Marc Mutz via Development wrote:
>> I like simple rules. "Overrides should have the same access level as the
>> initial virtual function." is a simple rule.
>
> But it makes no sense in general. The base class is the
On 3/15/24 18:09, Marc Mutz via Development wrote:
I like simple rules. "Overrides should have the same access level as the
initial virtual function." is a simple rule.
But it makes no sense in general. The base class is the interface, and
overrides should have the least possible visibility
On 15.03.24 14:28, Volker Hilsheimer via Development wrote:
>> On 15 Mar 2024, at 12:30, Marc Mutz via Development
>> wrote:
>> On 15.03.24 09:11, apoenitz wrote:
>>> On Fri, Mar 15, 2024 at 07:16:59AM +, Marc Mutz via Development wrote:
>> [...]
Please note that this means that any
On Monday, 5 February 2024 01:44:29 PDT Allan Sandfeld Jensen wrote:
> I was trying to drop support for it in qtwebengine in 6.7, but the problem
> was it was still used for qt packaging. But if we could at least switch
> packing to vs2022, it would mean we could drop it in QWE.
Can we commit to
> On 15 Mar 2024, at 12:30, Marc Mutz via Development
> wrote:
> On 15.03.24 09:11, apoenitz wrote:
>> On Fri, Mar 15, 2024 at 07:16:59AM +, Marc Mutz via Development wrote:
> [...]
>>> Please note that this means that any override (and all new QObject
>>> classes should contain one, since,
On 15.03.24 09:11, apoenitz wrote:
> On Fri, Mar 15, 2024 at 07:16:59AM +, Marc Mutz via Development wrote:
[...]
>> Please note that this means that any override (and all new QObject
>> classes should contain one, since, in case we ever need it, it might not
>> be possible to add it after the
On Fri, Mar 15, 2024 at 07:16:59AM +, Marc Mutz via Development wrote:
> Summary as of 2024-3-14 EOD: QObject::event() has to stay public.
Ok.
> Please note that this means that any override (and all new QObject
> classes should contain one, since, in case we ever need it, it might not
>
+1
From: Development on behalf of Tor Arne
Vestbø via Development
Sent: Thursday, March 14, 2024 10:06
To: development
Subject: [Development] Nominating Jøger Hansegård for approver rights
Hi,
I would like to nominate Jøger Hansegård for approver
+1!
Lars
> On 14 Mar 2024, at 10:06, Tor Arne Vestbø via Development
> wrote:
>
> Hi,
>
> I would like to nominate Jøger Hansegård for approver rights in the Qt
> project.
>
> Jøger joined The Qt Company 10 months ago and has since then been getting his
> hands dirty in Qt Multimedia, and
Summary as of 2024-3-14 EOD: QObject::event() has to stay public.
Please note that this means that any override (and all new QObject
classes should contain one, since, in case we ever need it, it might not
be possible to add it after the fact) should also be public.
Thanks,
Marc
On 13.03.24
20 matches
Mail list logo
