Is initialization order guaranteed?

[Dave]

#include <iostream>

using namespace std;

struct foo
{
int a;
int b;
};

int main()
{
int x = 5;

foo bar = {x = 1, x + 1};
cout << bar.a;
cout << bar.b << endl;

// Is this guaranteed to output "12"?
// Is it possible that this could output "16"?
}


Regards,
Dave

 

[vindhya]

Why should it give 12 or 16. Your statement (x=1,x+1) will assign the
value 1 to bar.a and 2 to bar.b.
So first cout will give 1 and next cout will give 2.
If you change your statement of initializing bar as
foo bar = {1,x+1}
then output will be 1 and 6.

 

[Dave]

Why should it give 12 or 16. Your statement (x=1,x+1) will assign the
value 1 to bar.a and 2 to bar.b.
So first cout will give 1 and next cout will give 2.
If you change your statement of initializing bar as
foo bar = {1,x+1}
then output will be 1 and 6.

Pasting the code back for reference...

#include <iostream>

using namespace std;

struct foo
{
int a;
int b;
};

int main()
{
int x = 5;

foo bar = {x = 1, x + 1};
cout << bar.a;
cout << bar.b << endl;

// Is this guaranteed to output "12"?
// Is it possible that this could output "16"?
}

What I'm asking is whether the initializers are guaranteed to be evaluated
in order. If the implementation is free to evaluate the initializers in any
order, some compiler might choose to evaluate x+1 before evaluating x = 1.
If this happened, the output would be 16.

 

[Stephen Howe]

Why should it give 12 or 16. Your statement (x=1,x+1) will assign the
value 1 to bar.a and 2 to bar.b.
So first cout will give 1 and next cout will give 2.

Right. And he is not outputting whitespace characters between integers, so
he should see "12" i.e. one integer outputted directly after the other.

Stephen Howe

 

[benben]

Why should it give 12 or 16. Your statement (x=1,x+1) will assign the
value 1 to bar.a and 2 to bar.b.
So first cout will give 1 and next cout will give 2.

so that would make "12" ("1" followed by "2")

 

[Ben Pope]

#include <iostream>

using namespace std;

struct foo
{
int a;
int b;
};

int main()
{
int x = 5;

foo bar = {x = 1, x + 1};
cout << bar.a;
cout << bar.b << endl;

// Is this guaranteed to output "12"?
// Is it possible that this could output "16"?
}

I believe the initialisation order is the order of declaration.

I.e., a then b, and the output will be "12" (newline, etc.)

Even if you had:

#include <iostream>

struct foo
{
int a;
int b;
foo(int val) : b(val + 1), a(val = 1) {}
};

int main(int argc, char* argv[])
{
//And called:
int x = 5;
foo bar = foo(x);
std::cout << bar.a << bar.b << x << std::endl;

return 0;
}

Then the order of initialisation is still the order of declaration (a and then b), not the order of the initialiser list.

Output is "125".

Ben

 

[msalters]

Ben Pope schreef:

I believe the initialisation order is the order of declaration.

True, but are you initializing b with 2 or with 6? If the compiler
uses some kind of stack, it could legally push x+1=6 and then x=1,
then pop 1 to initialize a and then pop 6 to initialize b. That is
still initialization in declaration order. The evaluation of
arguments is another question, and that's not ordered.

The actual output can also be "You're fired". The reason is the
code writes to and reads from x without an intervening sequence
point. That is undefined behavior, and that means all bets are off.

Regards,
Michiel Salters

 

[Ben Pope]

Ben Pope schreef:


True, but are you initializing b with 2 or with 6? If the compiler
uses some kind of stack, it could legally push x+1=6 and then x=1,
then pop 1 to initialize a and then pop 6 to initialize b. That is
still initialization in declaration order. The evaluation of
arguments is another question, and that's not ordered.

The actual output can also be "You're fired". The reason is the
code writes to and reads from x without an intervening sequence
point. That is undefined behavior, and that means all bets are off.

Which is probably why it looks ugly and feels wrong, anyway! Thanks for the clarification.

If you really can calculate the value of two members from one argument, perhaps you have redundant data, which is usually asking for trouble.

Ben