Ok, it looks like the thread is still on.
Call me wrong or everyday Bob or whatever. But here we go.

For me C++ should be intuitive to understand.
Armed with some logic and sense is enough to understand its construct. No need to run to the standard everytime to understand simple things unless there is a risk of legacy heritage from C.

In our case, Compilers implementers allowed rearranging the members initialization for a reason, i hope it is logic, right?
So if i have:
struct base {};
struct derived: public base{};
struct mostDerived: public derived
    int a;  
    double d;
    mostDerived(): d(3.14), a(123) {}

To get "mostDerived" constructed then i need "derived" constructed. 
In turn, to get "derived" constructed i need "base" constructed.
So obviously there is an ordering here.
It does make sense to abide to it.

My question now is: 
-why should i impose this ordering on the data members "a" and "d" in the "mostDerived" class?
-Isn't the same if I constructed "d" then "a" or the other way around?

Don't tell me the standard says. I want one logic reason or an example. 

Also, if my compiler allows me to shuffle the initialization order of data members. 
For me, that is a strong guarantee that it will catch the following case and process it without error:
Given the struct: base and derived above,
struct mostDerived: public derived
    int a;
    double d;
    mostDerived (): d(3.14), derived(), a(123){}

So logically,  the compiler should help me here and make sure that this constructor produce correct code, right?
Otherwise i need always to compile my constructor myself before my compiler does it. Which is not programming for me.

So my proposal,  or suggestion,  is relaxing this ordering rule on data member initialization. 

But if this flexibility is not desired, and ppl are content with what they have, then it's ok.

I will stop here.


Sent from my Galaxy

-------- Original message --------
From: Jason McKesson via Std-Proposals <std-proposals@lists.isocpp.org>
Date: 2/25/22 10:46 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 Fri, Feb 25, 2022 at 12:30 PM organicoman via Std-Proposals
<std-proposals@lists.isocpp.org> wrote:
>  Keep in mind that objects are guaranteed to be destroyed in the opposite order of construction. If you have multiple constructors that may construct your subobjects in different orders, you must also allocate run-time memory to record the order of initialization in order for your destructor to destroy the objects in the correct order. That's an unacceptable cost to a lot of people.
> What you are talking about here, and i guess most of the participant in this discussion,  is the base classes of a derived class (known as subobjects).
> For that case. Yes, the order of destruction MUST follow the order of construction in reverse, and that is guaranteed by the standard.
> In our case we are talking about " MEMBER Objects", objects declared inside the body of the structure.

Members are a *kind* of subobject.

> The compiler is free to rearrange their layout however it sees fit for a compact memory and to avoid extra instruction to fetch a member if it is not at the right memory boundary.

The compiler is permitted to insert padding, but it's permitted to do
that for *any* subobject, base or member. What the compiler is *not*
allowed to do is rearrange the *order* of members entirely. There are
cases where the compiler can, but since C++11, that is restricted
specifically to cases where some members are of different access
classes, and this reordering can only happen *between* members of
different access classes. Within an access classes, later members must
come after earlier ones.

This is explicitly codified in C++20's pointer comparison rules:

> If two pointers point to different non-static data members of the same object, or to subobjects of such
members, recursively, the pointer to the later declared member is
required to compare greater provided
the two members have the same access control (11.9), neither member is
a subobject of zero size, and
their class is not a union.

So your conclusion arises from faulty premises. The layout of a struct
must be such where later declared members are later in the object than
earlier ones, within the same access control. Ordering is not subject
to the compiler's whims.
Std-Proposals mailing list