Date: Fri, 25 Feb 2022 12:46:56 -0500
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.
There is no difference. The Standard's rules apply to all subobjects,
whether they are base subobjects, member subobjects, or even the elements
of an array.
You can learn all about initialization order
- in the standard
- on cppreference
- in a vast number of blog posts and articles
- in a vast number of videos online
*Everyone* in this thread has told you that your ideas and explanations are
wrong. That is because *you are wrong*. We understand what you're claiming.
What you're claiming is just *wrong*.
> 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.
> Imagine this situation:
> struct object
> {
> char c;
> int i;
> short s;
> };
>
> Obviously the compiler can, and maybe must, move the char member object,
to the end of the list of members and add some padding to make the memory
compact and at 4's. Making the order of initialization irrelevant.
No. `struct object` here is a standard-layout type. The standard guarantees
that c, i, s are laid out in that order, and in fact that offsetof(object,
c)==0.
Again, you can read all about the rules of C++
- in the standard
- on cppreference
- in a vast number of blog posts and articles
- in a vast number of videos online
> [...] So, i think we need to make the order of initialization of data
members, irrelevant. And separate it from the subobjects initialization.
> And keep all the rest.
> What do you think?
That paragraph is a proposal of how you (currently) think C++ should work.
As a proposal, it's *on-topic* for std-proposals.
But, it's fundamentally unworkable. (See Chris Ryan's explanation, two
messages up from this one.) So, it's a bad idea.
Please, stop arguing with all the experts until you have played around with
C++ on godbolt.org a little bit and seen with your own eyes how things work
in this language.
–Arthur
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.
There is no difference. The Standard's rules apply to all subobjects,
whether they are base subobjects, member subobjects, or even the elements
of an array.
You can learn all about initialization order
- in the standard
- on cppreference
- in a vast number of blog posts and articles
- in a vast number of videos online
*Everyone* in this thread has told you that your ideas and explanations are
wrong. That is because *you are wrong*. We understand what you're claiming.
What you're claiming is just *wrong*.
> 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.
> Imagine this situation:
> struct object
> {
> char c;
> int i;
> short s;
> };
>
> Obviously the compiler can, and maybe must, move the char member object,
to the end of the list of members and add some padding to make the memory
compact and at 4's. Making the order of initialization irrelevant.
No. `struct object` here is a standard-layout type. The standard guarantees
that c, i, s are laid out in that order, and in fact that offsetof(object,
c)==0.
Again, you can read all about the rules of C++
- in the standard
- on cppreference
- in a vast number of blog posts and articles
- in a vast number of videos online
> [...] So, i think we need to make the order of initialization of data
members, irrelevant. And separate it from the subobjects initialization.
> And keep all the rest.
> What do you think?
That paragraph is a proposal of how you (currently) think C++ should work.
As a proposal, it's *on-topic* for std-proposals.
But, it's fundamentally unworkable. (See Chris Ryan's explanation, two
messages up from this one.) So, it's a bad idea.
Please, stop arguing with all the experts until you have played around with
C++ on godbolt.org a little bit and seen with your own eyes how things work
in this language.
–Arthur
Received on 2022-02-25 17:47:07