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.NadirSent from my Galaxy
-------- Original message --------From: Jason McKesson via Std-Proposals <std-proposals_at_[hidden]> Date: 2/25/22 10:46 PM (GMT+04:00) To: std-proposals_at_[hidden] Cc: Jason McKesson <jmckesson_at_[hidden]> 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_at_[hidden]> 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 dothat for *any* subobject, base or member. What the compiler is *not*allowed to do is rearrange the *order* of members entirely. There arecases where the compiler can, but since C++11, that is restrictedspecifically to cases where some members are of different accessclasses, and this reordering can only happen *between* members ofdifferent access classes. Within an access classes, later members mustcome 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 suchmembers, recursively, the pointer to the later declared member isrequired to compare greater providedthe two members have the same access control (11.9), neither member isa subobject of zero size, andtheir class is not a union.So your conclusion arises from faulty premises. The layout of a structmust be such where later declared members are later in the object thanearlier ones, within the same access control. Ordering is not subjectto the compiler's whims.-- Std-Proposals mailing listStd-Proposals_at_[hidden]://lists.isocpp.org/mailman/listinfo.cgi/std-proposals