# Ampersand after type

This topic is 4865 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

I saw this function somewhere and have a question about how it has been declared. Can someone please explain the purpose of having the ampersand (&) after the function return type. I thought it meant the function would return a reference, but this function returns the de-referenced (*this) pointer, which I don't think is a reference.
[SOURCE]
// *************************************************************************
// createVector
// RETURN THE VECTOR BEWEEN TWO POINTS.
// *************************************************************************
template < typename tType >
inline const cl_3dVector < tType > & createVector(const cl_3dPoint < tType > & tail, const cl_3dPoint < tType > & head)
{
return *this;
}
[/SOURCE]

##### Share on other sites
The result of dereferencing a pointer is a reference to the object that the pointer points to. So yes, it's returning a reference to the object.

##### Share on other sites
I sorta get it. So if this function's return type was double and it was only returning say the x component of the vector "return (this->x);", then you would not need the ampersand symbol because the function is returning a type double and not an object. Does that sound right?

##### Share on other sites
Well, you could return a reference to x with a double &, but that's usually not so happy.

##### Share on other sites
Of course, but in that case you would be returning "return *(this->x);", which I agree is not happy.

##### Share on other sites
No, it would just be this->x. this->x is already a double &, you can't dereference it any further.

##### Share on other sites
Then would you mind explaining where the unhappiness might arise from?

##### Share on other sites
Returning direct references to a class' internals is rarely a good idea. Either they should just be public variables, so you don't need to have a function that returns a reference, or they should be insulated behind class functions that can maintain their invariants.

##### Share on other sites
Cool stuff. Well thanks for all the information.

##### Share on other sites
I find that it helps to think of references, not as part of a variable's type, but as a calling convention - thus, "return a cl_3dVector< tType > by reference" - and then you indeed return such a thing (*this), and the & just causes it to be returned by reference.

The result of returning it by reference is that the same value is used, rather than a copy. That's not so much an optimization (the compiler is pretty good at removing useless copies) as a useful design trick: references can be used as l-values, so for example you could do createVector(myTail, myHead).doSomething();. It is often the case that member operators will return *this by reference, so that you can "chain" them; this is how things like "cout << foo << bar" work - the result of "cout << foo" is cout, with the printing happening as a side effect, so then "cout << bar" gets evaluated (again printing as a side effect and yielding a reference to cout - but this time there is no more to do, so that reference is just thrown on the floor - note that "cout;" is also a valid C++ statement).

• ### What is your GameDev Story?

In 2019 we are celebrating 20 years of GameDev.net! Share your GameDev Story with us.

• 14
• 12
• 29
• 11
• 44
• ### Forum Statistics

• Total Topics
634856
• Total Posts
3019659
×