Are there any undefined behavior issues when moving data into a function and then back out to where it came from?

Question

Consider the following function:

std::vector<int> pushIt(std::vector<int> v){
    v.push_back(10);
    return v; 
}

int main(){
    std::vector<int> vec;
    vec = pushIt(std::move(vec));
}

my assumption is that the vector is moved into the function, modified and moved back to its original spot. This should result in simmilar behavior as passing it in as a non const reference. This seems to be quite valid behavior but a colleague fears undefined behavior. Is there anything I am missing here?

I would like to do this because the current function

void currentPushIt(std::vector<int>& v){
    v.push_back(10);
}

has led to a lot of problems in code review because people overlook the fact that an innocent call to currentPushIt(v) can invalidate iterators. Making them write v=pushIt(std::move(v)) should wake them up enough that they don't make the same mistakes.

It's a little bit unconventional. Any reason why you can't just use a new variable to store the return type? — ComicSansMS, Mar 20 '14 at 16:54
Note that in old (pre-C++11) compilers, the pass-by-value version might copy the entire contents of the vector. — user253751, Mar 23 '14 at 05:25

score 2 · Accepted Answer · answered Mar 20 '14 at 17:00

2

Per 1.9p15, the value computations and side effects associated with the argument are sequenced before the execution of the body of the function. So already by the time you enter pushIt the source vec has been moved from. The assignment is then sequenced after the execution of pushIt, since you are actually calling the user-defined operator vector::operator=:

vec.operator=(       // sequenced after
    pushIt(          // the evaluation of this, which is sequenced after
        std::move(   // the evaluation of this
            vec)))

So your code is fine.

answered Mar 20 '14 at 17:00

ecatmur

152,476
27
293
366

Would there be an issue if he had not used std::move() to the PushIt() call? If so then the function is not safe at all because every single call would require the user to remember to use std::move() which is very much prone to errors. – Alexis Wilke Mar 20 '14 at 17:13
@AlexisWilke if `std::move` is omitted, then `vec` is *copied* to create the parameter `v` used inside and returned from `pushIt`. Again, the copying is sequenced before the body of `pushIt`. – ecatmur Mar 20 '14 at 17:17
Will `vec` remain a valid object had the user used `std::vector vec2 = pushIt(std::move(vec));`? – R Sahu Mar 20 '14 at 17:29
@RSahu yes, `vec` will be in a valid but undetermined state (usually, empty). – ecatmur Mar 20 '14 at 17:32
I wonder what the standard says about the state of the object from which a user moves data. I am dreading to hear "undefined behavior". – R Sahu Mar 20 '14 at 17:52
@RSahu [lib.types.movedfrom]/1: "Objects of types defined in the C++ standard library may be moved from (12.8). Move operations may be explicitly specified or implicitly generated. Unless otherwise specified, such moved-from objects shall be placed in a valid but unspecified state." – Casey Mar 20 '14 at 18:00
@Casey it's good to know that the program won't crash if you use an object from which data have been moved. Perhaps there is an unspecified but commonly implemented behavior. – R Sahu Mar 20 '14 at 18:09
@RSahu read http://stackoverflow.com/questions/17730689/is-a-moved-from-vector-always-empty – ecatmur Mar 20 '14 at 18:11

score 1 · Answer 2 · answered Mar 20 '14 at 17:07

Your colleagues fear is without reason, the snippet shown does not suffer from undefined behavior.

The snippet written, since std::vector is a class, is equivalent of the below, and since a function parameter must have a value before the function is called it's equivalent of first calling std::move, then pushIt, and later vec.operator=.

When viewed in this way it's quite clear that it's actually safe to write such code as you have done.

vec.operator= (pushIt (std::move (vec));

In general

a = do_something (a);

I've met developers who get worried about such snippets because = isn't a sequence-point; what if do_something modifies a, what happens to the left-hand side?

long story short; It doesn't matter. Even though we don't know in which order the left-hand side and the right-hand side will be evaluated it is well-defined in terms of correctness.

The left-hand side of = is an lvalue, which can be seen as a location of where a certain value will end up. No matter the value stored at this location, the actual location will always be the same.

The right-hand side will, in this case, move from vec. This will indoubtely change the value of vec, but it won't change the location of where vec is; so the result of the right-hand side will correctly be assigned to where it's supposed to.

^{Note: The actual assignment is sequenced, both lhs and rhs must be evaluated before this takes place (ie. before the value of rhs is assigned to the location yield by lhs), but the order of which lhs and rhs is evaluated is not set in stone.}

Yakk - Adam Nevraumont · Answer 3 · 2014-03-20T18:02:42.797

0

Is there any undefined behavior issues when moving data into a function and then back out to where it came from?

No.

Function arguments are evaluated "sequenced-before" function evaluation. Assignment is "sequenced-after" the right-hand side evaluation.

edited Mar 20 '14 at 18:02

answered Mar 20 '14 at 16:59

Yakk - Adam Nevraumont

262,606
27
330
524

2

To clarify, does "no" mean "there are no issues" or "don't do that"? – Mike Seymour Mar 20 '14 at 17:01
@MikeSeymour I directly answered the question in the title of the post. Should be clear! – Yakk - Adam Nevraumont Mar 20 '14 at 17:16

Are there any undefined behavior issues when moving data into a function and then back out to where it came from?

3 Answers3

In general