Doh!
I meant data members.
Wow the proposal examples was so misleading, i was thinking about data members construction after reading the examples then i extrapolated to base classes.
Yes, as Jason pointed, base classes initialization order is well defined.
But data members of an object, as the proposal points to in its example, can be constructed in different order, at best you will have a compiler warning telling you that you initialized some data member before the other.
class PublicInterface {
std::unique_ptr<class Impl> pimpl_;
};
"pimpl_", is data member not a base class (subobject)
Thanks Jason, nice catch, it was lucid 👌
Nadir
-------- Original message --------
From: Jason McKesson via Std-Proposals <std-proposals@lists.isocpp.org>
Date: 2/24/22 6:41 PM (GMT+04:00)
To: std-proposals@lists.isocpp.org
Cc: Jason McKesson <jmckesson@gmail.com>
Subject: Re: [std-proposals] Relax condition for potentially invoked
destructor in constructor
On Thu, Feb 24, 2022 at 8:22 AM organicoman via Std-Proposals
<std-proposals@lists.isocpp.org> wrote:
> But remember that the compiler is free to rearrange the construction of subobjects for optimization purposes,
Um, no it isn't. The order of initialization of subobjects is
well-defined ([class.base.init]/13: declaration order, base classes
first) and not allowed to vary. Compilers are not free to re-order
those subobject constructors.
The OP's point therefore stands: if all of the constructors for
subobjects past a certain point are not potentially throwing, then
none of their destructors *need* to be potentially invoked.
That said, I don't think it's a very *useful* idea. It makes
"potentially invoked" a matter of exactly how you initialize an
object, which sounds very brittle. One constructor might consider
certain destructors to be "potentially invoked" while another may not.
And I'm not sure what any of this would actually purchase you in terms
of useful functionality.
--
Std-Proposals mailing list
Std-Proposals@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals