Functions in C++ can return a reference as it's returns a pointer. When function returns a reference it means it returns a implicit pointer.
It is dangerous to have a dangling pointer like that as pointers or references to local variables are not allowed to escape the function where local variables live; hence, the compiler throws an error.
A C++ function can return a reference in a similar way as it returns a pointer. When returning a reference, be careful that the object being referred to does not go out of scope. So it is not legal to return a reference to local var. But you can always return a reference on a static variable.
The major advantage of return by address over return by reference is that we can have the function return nullptr if there is no valid object to return.
In general, returning a reference is perfectly normal and happens all the time.
If you mean:
int& getInt() {
int i;
return i; // DON'T DO THIS.
}
That is all sorts of evil. The stack-allocated i
will go away and you are referring to nothing. This is also evil:
int& getInt() {
int* i = new int;
return *i; // DON'T DO THIS.
}
Because now the client has to eventually do the strange:
int& myInt = getInt(); // note the &, we cannot lose this reference!
delete &myInt; // must delete...totally weird and evil
int oops = getInt();
delete &oops; // undefined behavior, we're wrongly deleting a copy, not the original
Note that rvalue references are still just references, so all the evil applications remain the same.
If you want to allocate something that lives beyond the scope of the function, use a smart pointer (or in general, a container):
std::unique_ptr<int> getInt() {
return std::make_unique<int>(0);
}
And now the client stores a smart pointer:
std::unique_ptr<int> x = getInt();
References are also okay for accessing things where you know the lifetime is being kept open on a higher-level, e.g.:
struct immutableint {
immutableint(int i) : i_(i) {}
const int& get() const { return i_; }
private:
int i_;
};
Here we know it's okay to return a reference to i_
because whatever is calling us manages the lifetime of the class instance, so i_
will live at least that long.
And of course, there's nothing wrong with just:
int getInt() {
return 0;
}
If the lifetime should be left up to the caller, and you're just computing the value.
Summary: it's okay to return a reference if the lifetime of the object won't end after the call.
No. No, no, a thousand times no.
What is evil is making a reference to a dynamically allocated object and losing the original pointer. When you new
an object you assume an obligation to have a guaranteed delete
.
But have a look at, eg, operator<<
: that must return a reference, or
cout << "foo" << "bar" << "bletch" << endl ;
won't work.
You should return a reference to an existing object that isn't going away immediately, and where you don't intend any transfer of ownership.
Never return a reference to a local variable or some such, because it won't be there to be referenced.
You can return a reference to something independent of the function, which you don't expect the calling function to take the responsibility for deleting. This is the case for the typical operator[]
function.
If you are creating something, you should return either a value or a pointer (regular or smart). You can return a value freely, since it's going into a variable or expression in the calling function. Never return a pointer to a local variable, since it will go away.
I find the answers not satisfactory so I'll add my two cents.
Let's analyze the following cases:
int& getInt()
{
int x = 4;
return x;
}
This is obviously error
int& x = getInt(); // will refer to garbage
int& getInt()
{
static int x = 4;
return x;
}
This is right, because static variables are existant throughout lifetime of a program.
int& x = getInt(); // valid reference, x = 4
This is also quite common when implementing Singleton pattern
Class Singleton
{
public:
static Singleton& instance()
{
static Singleton instance;
return instance;
};
void printHello()
{
printf("Hello");
};
}
Usage:
Singleton& my_sing = Singleton::instance(); // Valid Singleton instance
my_sing.printHello(); // "Hello"
Standard library containers depend heavily upon usage of operators which return reference, for example
T & operator*();
may be used in the following
std::vector<int> x = {1, 2, 3}; // create vector with 3 elements
std::vector<int>::iterator iter = x.begin(); // iterator points to first element (1)
*iter = 2; // modify first element, x = {2, 2, 3} now
There are times when & may be used for quick access to internal data
Class Container
{
private:
std::vector<int> m_data;
public:
std::vector<int>& data()
{
return m_data;
}
}
with usage:
Container cont;
cont.data().push_back(1); // appends element to std::vector<int>
cont.data()[0] // 1
HOWEVER, this may lead to pitfall such as this:
Container* cont = new Container;
std::vector<int>& cont_data = cont->data();
cont_data.push_back(1);
delete cont; // This is bad, because we still have a dangling reference to its internal data!
cont_data[0]; // dangling reference!
It's not evil. Like many things in C++, it's good if used correctly, but there are many pitfalls you should be aware of when using it (like returning a reference to a local variable).
There are good things that can be achieved with it (like map[name] = "hello world")
"returning a reference is evil because, simply [as I understand] it makes it easier to miss deleting it"
Not true. Returning a reference does not imply ownership semantics. That is, just because you do this:
Value& v = thing->getTheValue();
...does not mean you now own the memory referred to by v;
However, this is horrible code:
int& getTheValue()
{
return *new int;
}
If you are doing something like this because "you don't require a pointer on that instance" then: 1) just dereference the pointer if you need a reference, and 2) you will eventually need the pointer, because you have to match a new with a delete, and you need a pointer to call delete.
There are two cases:
const reference --good idea, sometimes, especially for heavy objects or proxy classes, compiler optimization
non-const reference --bad idea, sometimes, breaks encapsulations
Both share same issue -- can potentially point to destroyed object...
I would recommend using smart pointers for many situations where you require to return a reference/pointer.
Also, note the following:
There is a formal rule - the C++ Standard (section 13.3.3.1.4 if you are interested) states that a temporary can only be bound to a const reference - if you try to use a non-const reference the compiler must flag this as an error.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With