5

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?

Improve this question
2
  • 4
    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? Commented Aug 21, 2011 at 14:46
  • 2
    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++. Commented Sep 13, 2013 at 18:41

3 Answers 3

Reset to default
15

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.

Improve this answer
Sign up to request clarification or add additional context in comments.

2 Comments

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.
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?
2

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.

Improve this answer

1 Comment

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.
-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.

Improve this answer

1 Comment

This is absolutely incorrect as a general statement. Maybe you can clarify or provide a reference to what specifically you are talking about?

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.