Problem with returning arguments that are const references

Question

I know why the following does not work correclty, so I am not asking why. But I am feeling bad about it is that it seems to me that it is a very big programming hindrance.

#include <iostream>
#include <string>
using namespace std;

string ss("hello");

const string& fun(const string& s) {
        return s;
}

int main(){
        const string& s = fun("hello");
        cout<<s<<endl;
        cout<<fun("hello")<<endl;
}

The first cout will not work. the second cout will.

My concern is the following:

Is it not possible to imagine a situation where a method implementor wants to return an argument that is a const reference and is unavoidable?
I think it is perfectly possible.
What would you do in C++ in this situation?

Thanks.

Answer 1

The technique is valid and is used all the time. However in your first example you are converting a const char* to a temporary std::string and attempting to return it, which is not the same as returning a const-reference to an object stored elsewhere. In the second example you are doing the same thing, but you are using the result before the temporary is destroyed, which in this case is legal but dangerous (see your first case.)

Update: Allow me to clarify my answer some. I'm saying the problem lies in the creation of the temporary and not correctly handling the lifetimes of the objects being created. The technique is a good one, but it (along with many other good techniques) requires the pre- and post-conditions of the functions be met. Part of this burden falls on the function programmer (who should document it) and partly on the client as well.

Answer 2

Yes, I agree that there are situations where this is a relevant problem.

I would use a reference-counted pointer to "solve" it.

Answer 3

Is it not possible to imagine a situation where a method implementor wants to return an argument that is a const reference and is unavoidable?

Wrong question to ask, really. All you have to do is include whether the returned reference might be to a parameter (passed by reference), and document that as part of the interface. (This is often obvious already, too.) Let the caller decide what to do, including making the temporary into an explicit object and then passing that.

It is common and required to document the lifetimes of returned pointers and references, such as for std::string::data.

What would you do in C++ in this situation?

Often you can pass and return by value instead. This is commonly done with things like std::copy (for the destination iterator in this case).

Answer 4

I feel your pain. I've found other situations where returning a const reference seemed the right thing to do, but had other ugly issues.

Luckily, the subtle gotcha is solved in c++0x. Always return by value. The new move constructors will make things a fast as you could wish.

Answer 5

In the upcoming C++ standard, r-value references can be used to keep your temporary objects 'alive' and would fix the issue that you're having.

You may want to look up perfect forwarding and move constructors as well.

Answer 6

I think you are asking for trouble in C++98 :)

This can be solved in two ways. First, you could use a shared pointer. In this case, the memory would be managed automatically by the shared_ptr, and you are done! But, this is a bad solution in most cases. Because you are really not sharing the memory between many references. auto_ptr is the true solution for this problem, if you consider using the heap all the time. auto_ptr needs one little crucial improvement that is not there in C++98 to be really usable, that is : Move Semantic!

A better solution is to allow ownership to be moved between references, by using r-value references, which is there in C++0x. So, your piece of code would look like(not sure if the syntax is correct):

string fun(const string& s) {
        return s; // return a copy of s
}
....
string s = fun("Hello"); // the actual heap memory is transfered to s.
                         // the temporary is destroyed, but as we said
                        // it is empty, because 's' now owns the actual data!

Answer 7

In C++, it is important to establish the lifetimes of objects. One common technique is to decide upon an "owner" for each object. The owner is responsible for ensuring that the object exists as long as it is needed, and deleting it when not needed.

Often, the owner is another object that holds the owned object in an instance variable. The other typical ways to deal with this are to make it a global, a static member of a class, a local variable, or use a reference-counted pointer.

In your example, there is no clear ownership of the string object. It is not owned by the main() function, because it is not a local variable, and there is no other owner.

Answer 8

I think it is a slight weakness of C++. There's an unfortunate combination of two factors:

• The function's return is only valid as long as its argument is.
• Implicit conversion means that the function's argument is not the object it may appear to be.

I have no sympathy for people who fail to think about the lifetime of objects they have pointers/references to. But the implicit conversion, which certainly is a language feature with subtle pros and cons, is not making the analysis very easy here. Sometimes implicit conversion is bad news, which why the explicit keyword exists. But the problem isn't that conversion to string is bad in general, it's just bad for this function, used in this incorrect way.

The author of the function can in effect disable implicit conversion, by defining an overload:

const char *fun(const char *s) { return s; }

That change alone means the code which previously was bad, works. So I think it's a good idea in this case to do that. Of course it doesn't help if someone defines a type which the author of fun has never heard of, and which has an operator std::string(). Also, fun is not a realistic function, and for more useful routines you might not want to provide an equivalent which operates on char*. In that case, void fun(const char *); at least forces the caller to explicitly cast to string, which might help them use the function correctly.

Alternatively, the caller could note that he's providing a char*, and getting back a reference to a string. That appears to me to be a free lunch, so alarm bells should be ringing where this string came from, and how long it's going to last.