Date: Tue, 30 Jun 2026 09:51:42 -0700
On Tuesday, 30 June 2026 09:18:13 Pacific Daylight Time Ruud Rietvink via Std-
Proposals wrote:
> In the constructor and destructor of an object you cannot use virtual
> methods properly.
> So calling a virtual method in a base class to get some possible derived
> value is not possible.
I would call that this is *properly*.
> Proposal is to introduce an initializer method that is automatically
> called after the construction is complete,
> and a finalizer method that is automatically called before the
> destruction of an object.
That is an interesting idea, one I have needed several times in the last 25
years.
For example, with QObject, we report signal disconnections using a virtual
method called disconnectNotify(). Obviously that is useless when run from the
actual ~QObject destructor, when all signals are disconnected, because the
user's class that may have overridden the function has already been destroyed.
So we can't.
Widgets also have needed such a post-construction solution. We want the
derived classes to have constructed and initialised themselves, so QWidget
posts an event back to itself (the PolishEvent) so that post-initialisation
activities are carried on the event loop soon after. But all classes need to
be aware that the user code may attempt to access state before this event has
been delivered and processed.
Proposals wrote:
> In the constructor and destructor of an object you cannot use virtual
> methods properly.
> So calling a virtual method in a base class to get some possible derived
> value is not possible.
I would call that this is *properly*.
> Proposal is to introduce an initializer method that is automatically
> called after the construction is complete,
> and a finalizer method that is automatically called before the
> destruction of an object.
That is an interesting idea, one I have needed several times in the last 25
years.
For example, with QObject, we report signal disconnections using a virtual
method called disconnectNotify(). Obviously that is useless when run from the
actual ~QObject destructor, when all signals are disconnected, because the
user's class that may have overridden the function has already been destroyed.
So we can't.
Widgets also have needed such a post-construction solution. We want the
derived classes to have constructed and initialised themselves, so QWidget
posts an event back to itself (the PolishEvent) so that post-initialisation
activities are carried on the event loop soon after. But all classes need to
be aware that the user code may attempt to access state before this event has
been delivered and processed.
-- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Principal Engineer - Intel Data Center - Platform & Sys. Eng.
Received on 2026-06-30 16:51:58
