Move semantics & returning const values

Question

I have the habit (?!?!?) of returning everything as a "const" value. Like this...

struct s;

s const make_s();

s const &s0 = make_s();
s const s1 = make_s();

With move operations and r-value references and the following functions...

void take_s(s &&s0);
void take_s(s const &&s0);  //  Doesn't make sense

I can no longer write...

take_s(make_s());

The main reason I started using the convention of returning const values is to prevent someone from writing code like this...

make_s().mutating_member_function();

The use case is the following...

struct c_str_proxy {
    std::string m_s;

    c_str_proxy(std::string &&s) : m_s(std::move(s)) {
    }
};

c_str_proxy c_str(std::string &&s) {
    return c_str_proxy(s);
}

char const * const c_str(std::string const &s) {
    return s.c_str();
}

std::vector < std::string > const &v = make_v();
std::puts(c_str(boost::join(v, ", ")));

std::string const my_join(std::vector < std::string > const &v, char const *sep);

//  THE FOLLOWING WORKS, BUT I THINK THAT IS ACCIDENTAL
//  IT CALLS
//
//      c_str(std::string const &);
//
//  BUT I THINK THE TEMPORARY RETURNED BY
//
//      my_join(v, "; ")
//
//  IS NO LONGER ALIVE BY THE TIME WE ARE INSIDE
//
//      std::puts
//
//  AS WE ARE TAKING THE "c_str()" OF A TEMPORARY "std::string"
//
std::puts(c_str(my_join(v, "; ")));

Looks as if "returning const value" and r-value references don't mix in this particular use case. Is that right?

**Edit 0: Extra question...**

The object is temporary anyway. Why should "const" prevent moving? Why can't we move "const" temporaries?

I don't really see the rationale for returning const values in the first place. Why would you care about preventing people from calling a mutating member function on the returned object? — jalf, Aug 21 '11 at 14:46
An example of the const value return idiom can be found in Meyers, "More Effective c++", 1996, Item 6. Meyers recommends `const T operator++(int)` as a signature for postfix++. — Adam Burry, Sep 13 '13 at 18:41

score 14 · Accepted Answer · answered Aug 21 '11 at 14:51

You have two conflicting goals. On one hand, you want to prevent modifications from being made to the returned object, but on the other hand, you want to allow modifications to be made (that's what a move operation is. It modifies the source object, by stealing its internal resources).

You need to make up your mind. Do you want the object to be immutable, or do you want people to be able to modify it?

For what it's worth, I don't really see what you'd gain by returning const temporaries in the first place. Yes, you prevent people from calling a mutating member function on it, but why would you want to? At best, being able to do so can be useful, and at worst, it's a mistake that is easily avoided.

And what you're doing doesn't really make much sense. The entire point in a temporary is that it's going to go away in a moment, so who cares if it gets modified?

The entire idea behind rvalue references and move semantics is that temporaries are temporary, and so they can be modified without harming anyone.

Yes. The only case when you would want to return something that is const is when it is a reference or a pointer to an object that you do not want the caller to be able to change. Otherwise, let them change away. — AFoglia, Sep 22 '11 at 22:05
Actually, returning const rvalues is useful to prevent errors like : if (a * b = c) if the type of a*b can be assigned with c and can implicitly converted to bool... well. It is an edge case, but easy to avoid by returning user types as const. Testing on vc14 compiler I see that const rvalue returned by a function is still sent through to the move constructor. Is there anything new in C++14 that specifies this, or is this only a compiler specific optim? — , Mar 10 '17 at 19:45

score 1 · Answer 2 · answered Aug 21 '11 at 14:28

1

You might have actually trouble with local variable going out of scope.

c_str() returns a pointer to the internal buffer, so once the original variable goes out of scope, the pointer will be invalid.

answered Aug 21 '11 at 14:28

Šimon Tóth

35,456
20
106
151

I am aware of that, but the question is really about returning const values. I guess even with r-value references, returning const values prevents moving. What I used to consider as a good practice suddenly is incorrect. – zrb Aug 21 '11 at 14:34

score -3 · Answer 3 · answered Aug 21 '11 at 14:51

-3

There's no semantic meaning to a const qualifier on a return value. If you turn up the warning level on your compiler, it will emit a warning every time you do this.

answered Aug 21 '11 at 14:51

user566408

57
5

This is absolutely incorrect as a general statement. Maybe you can clarify or provide a reference to what specifically you are talking about? – wjl Nov 08 '11 at 22:29

Move semantics & returning const values

3 Answers3

Linked