Date: Thu, 24 Feb 2022 22:56:58 -0800
>" The choice of allowing you to specify members in the member
initialization list out of order from their order of initialization?
Honestly, I have no idea why that was ever legal."
Quickly looking I could not find the reference for it but I did not think
that it was ever legal.
Most every compiler I tested (on godbolt) did report it as a warning
(-Wreorder) with -Wall or /Wall.
"Initializer order does not match the declaration order" or something like
that depending on your compiler
It doesn't make sense that it should be allowed since the destruction order
must be the reverse order of construction.
You can't have many constructors use many orders of initialization but only
one destructor and it needs to use the reverse order (of declaration).
You can not have multiple destructors where each one destructs in reverse
order of construction depending on the constructor used.
If the destructor must be in reverse order of declaration, construction
must be in order of declaration as must be the member initialization list.
On Thu, Feb 24, 2022 at 6:24 PM Jason McKesson via Std-Proposals <
std-proposals_at_[hidden]> wrote:
> On Thu, Feb 24, 2022 at 6:40 PM organicoman via Std-Proposals
> <std-proposals_at_[hidden]> wrote:
> >
> > Hmm,
> > That means that tglhe following code will print nonsense.
> >
> > struct foo
> > {
> > foo()=delete;
> > foo(int _a) : a(_a) { printf("foo%d\n",a);}
> > };
> >
> > struct bar
> > {
> > bar()=delete;
> > bar(foo f) { printf("bar%d\n",f.a);}
> > };
> >
> > struct test
> > {
> > bar b;
> > foo f;
> > int a;
> > test(): b(f), f(a), a(22) {}
> > };
> >
> > int main()
> > {
> > test t;
> > return 0;
> > }
> >
> > So instead of receiving a compiler error of a default constructor
> deleted for both bar and foo, i will receive junk!!
>
> That's what happens when you use an object before it gets initialized.
>
> > I seldomly read the standard, but this situation was out of discussion
> for me, since i assumed that i will logically receive a compiler error,
> and constructing a dependency graph between the data members was not that
> difficult to figure out.
> > Can anyone explain the logic behind this choice of the standard?
>
> What choice exactly?
>
> The choice of allowing you to specify members in the member
> initialization list out of order from their order of initialization?
> Honestly, I have no idea why that was ever legal. There's probably a
> historical reason for it.
>
> The choice of allowing you to access an object's name before its
> initialization? That ship sailed in C.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
initialization list out of order from their order of initialization?
Honestly, I have no idea why that was ever legal."
Quickly looking I could not find the reference for it but I did not think
that it was ever legal.
Most every compiler I tested (on godbolt) did report it as a warning
(-Wreorder) with -Wall or /Wall.
"Initializer order does not match the declaration order" or something like
that depending on your compiler
It doesn't make sense that it should be allowed since the destruction order
must be the reverse order of construction.
You can't have many constructors use many orders of initialization but only
one destructor and it needs to use the reverse order (of declaration).
You can not have multiple destructors where each one destructs in reverse
order of construction depending on the constructor used.
If the destructor must be in reverse order of declaration, construction
must be in order of declaration as must be the member initialization list.
On Thu, Feb 24, 2022 at 6:24 PM Jason McKesson via Std-Proposals <
std-proposals_at_[hidden]> wrote:
> On Thu, Feb 24, 2022 at 6:40 PM organicoman via Std-Proposals
> <std-proposals_at_[hidden]> wrote:
> >
> > Hmm,
> > That means that tglhe following code will print nonsense.
> >
> > struct foo
> > {
> > foo()=delete;
> > foo(int _a) : a(_a) { printf("foo%d\n",a);}
> > };
> >
> > struct bar
> > {
> > bar()=delete;
> > bar(foo f) { printf("bar%d\n",f.a);}
> > };
> >
> > struct test
> > {
> > bar b;
> > foo f;
> > int a;
> > test(): b(f), f(a), a(22) {}
> > };
> >
> > int main()
> > {
> > test t;
> > return 0;
> > }
> >
> > So instead of receiving a compiler error of a default constructor
> deleted for both bar and foo, i will receive junk!!
>
> That's what happens when you use an object before it gets initialized.
>
> > I seldomly read the standard, but this situation was out of discussion
> for me, since i assumed that i will logically receive a compiler error,
> and constructing a dependency graph between the data members was not that
> difficult to figure out.
> > Can anyone explain the logic behind this choice of the standard?
>
> What choice exactly?
>
> The choice of allowing you to specify members in the member
> initialization list out of order from their order of initialization?
> Honestly, I have no idea why that was ever legal. There's probably a
> historical reason for it.
>
> The choice of allowing you to access an object's name before its
> initialization? That ship sailed in C.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
Received on 2022-02-25 06:57:12