Assignment operation in member initializer lists

Question

I have the following Stack class.

class Stack{
public:
    int size;
    int* x;
    Stack() : size(10), x(new int[10]) {}
    Stack(const Stack& s) : x(new int[size=s.size]) {}

};

Notice the assignment in the copy constructor. The code works, compile fine and compiler (gcc) doesn't complain even with -Wall -Wextra flags. Does the compiler automatically rewrite the compiler to this?

Stack(const Stack& s) : size(s.size), x(new int[size]) {}

Or is there some other magic? I noticed when I change the definition order, the compiler complaints about not-in-order initialization. So I assume it's the case I mentioned. I couldn't find anything in the documentation and the ASM output doesn't help me either.

score 4 · Accepted Answer · edited Jun 20 '20 at 09:12

Does the compiler automatically rewrite the compiler to this?
Stack(const Stack& s) : size(s.size), x(new int[size]) {}

No.

Stack(const Stack& s) : x(new int[size=s.size]) {}

can be though of as being

Stack(const Stack& s) : size(), x(new int[size=s.size]) {}

but it isn't really since actually writing size() would value initialize it, meaning it is zero initialized, but since it is the compiler that synthesizes the initialization, default initialization^[1] happens meaning it is not initialized. Then you assign a value to it in x's initialization. This is "safe", meaning it works in this case, but I wouldn't recommend it it.

Stack(const Stack& s) : size(s.size), x(new int[s.size]) {}

initializes both members and if you ever change the order of them in the class, you will still have the correct behavior.

Gotta love a programming language where initialization requires an entire thesis, eh? :) Sorry for nitpicking, but it's dangerous ground the OP is on anyway. — StoryTeller - Unslander Monica, Mar 07 '19 at 13:53
@StoryTeller No worries. I'd rather have the nit picked since it is a long way down the rabbit hole :) — NathanOliver, Mar 07 '19 at 13:54

StoryTeller - Unslander Monica · Answer 2 · 2019-03-07T13:51:12.343

2

Members of a class are always initialized in order of declaration, regardless of the order you specify them in the member initialization list. And if you omit them, they are default initialized. So doing this:

Stack(const Stack& s) : x(new int[size=s.size]) {}

Means that size is default initialized first. That leaves it with an indeterminate value (as fundamental types are supposed to be default-initialized). Then the initializer for x is evaluated. Part of evaluating new int[size=s.size] involves the assignment expression size=s.size, which modifies size as a side effect. So your code is correct here, despite being likely to raise eyebrows.

When you switch the order of the members around, then the assignment happens before size is supposed to be initialized. That leaves your code code open to undefined behavior.

edited Mar 07 '19 at 13:51

answered Mar 07 '19 at 13:36

StoryTeller - Unslander Monica

165,132
21
377
458

Are you sure that the assignment has to happen *after* the default initialization? (Is it *sequenced after*?) – Martin Bonner supports Monica Mar 07 '19 at 13:39
@MartinBonner - I vaguely recall reading it once. Let me double check. – StoryTeller - Unslander Monica Mar 07 '19 at 13:39
1

@MartinBonner It is. [there is a note here](https://timsong-cpp.github.io/cppwp/class.init#class.base.init-7), and I can find the actual clause that applies if you really need it. – NathanOliver Mar 07 '19 at 13:41
1

@MartinBonner - Couple https://timsong-cpp.github.io/cppwp/intro.execution#5.4 with https://timsong-cpp.github.io/cppwp/intro.execution#9 and consider that intiialization proceeds in declaration order. So, yes, I'm sure now. – StoryTeller - Unslander Monica Mar 07 '19 at 13:44

score 0 · Answer 3 · answered Mar 07 '19 at 13:35

From the Cppreference.com page on constructors:

Names that appear in expression-list or brace-init-list are evaluated in scope of the constructor:

So yes, size here refers to this->size in the scope of the constructor, and the assignment size=s.size is a valid expression.

It goes without saying that you should not expect this to pass a code review :)

Quimby · Answer 4 · 2019-03-07T13:48:10.803

No, it rewrites it to this:

class Stack{
public:
    int size;
    int* x;
    Stack() : size(10), x(new int[10]) {}
    Stack(const Stack& s) :size(), x(new int[size=s.size]) {}
};

size() would be a default constructor for the object size but ints don't have one, so its just an empty statement and size remains uninitialized. ~~Or does it?~~

I would say this code might generate undefined behavior. The member variables are initialized in the order in which they are declared as per 10.9.2 Initializing bases and members. But the evaluation order of the expressions used for the initialization is not defines. So, size=s.size can be called either before or after size(). For class types that would be a problem, but I am not sure whether size() is guaranteed to be no-op and whether the compiler might decide to initialize the variable to e.g. 0.

See the comments under Story Teller's answer. It is not undefined behaviour (but very smelly anyway). — Martin Bonner supports Monica, Mar 07 '19 at 13:48
@MartinBonner Oh, didn't see it while writing my answer. Thank you. — Quimby, Mar 07 '19 at 13:49

Assignment operation in member initializer lists

4 Answers4