Jump to content
  • Advertisement
Sign in to follow this  
Winegums

references in C++

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

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi, I've been reviewing my knowledge of C++ and noticed that I don't really understand how a reference works. I mean I know how to use them, but I don't understand how they work. Pointers store an address, and objects store some data, but do references store some sort of pointer-like object that says "go to that guy over there"? (as opposed to pointers which say "go to address 0x...") I can see that they're the same size as the object they alias (which makes sense, since they're an alias). From what I see their benefits are the following: Vs Passing variables Explicitly - No need to impliment a copy-constructor (and also process time is saved by not calling said constructor) - Modifies object directly, no need to pass return values. Vs Pointers - Garunteed to be an object (as opposed to a pointer which can be NULL)

Share this post


Link to post
Share on other sites
Advertisement
They are generally implemented with pointers, except in the case of function inlining or const references to function return values (!). That's not a useful thing to know, though, unless you plan to be writing your own C++ compiler or debugging assembly code. In terms of when you should use a reference as opposed to a pointer, these are some pretty standard recommendations.

Share this post


Link to post
Share on other sites
Another question I had (but forgot to ask) is is there a performance benefit to using pointers as opposed to references when dealing with large objects? Since your pointer is only storing an address(and so will be a constant size of something like 4 bytes), but your reference will be as big as the object, which could be far more.

Share this post


Link to post
Share on other sites
They are probably implemented just as pointers, except at compile time different rules are observed (e.g sizeof is the size of the referenced object, since a reference is supposed to behave like an alias, etc).

Quote:

- No need to impliment a copy-constructor...


If you'd need to implement it yourself (if the shallow copy is not good enough), then you still either have to do it or make the class non-copyable (by making the copy-constructor private, or by inheriting from a base class with a private copy-constructor), either to provide a needed functionality (copies may need to be done elsewhere) or to avoid runtime errors (by passing something by value accidentally).

Quote:

Garunteed to be an object (as opposed to a pointer which can be NULL)


Guaranteed as long as you don't do anything wrong :), although conveying that message. Wrong things to do include returning references to local objects, having references to things which have been deallocated, initializing a reference with itself (int& i = i; - similar thing has happened to me), initializing a reference by dereferencing a NULL pointer and probably others.

Probably one reason they were introduced is operator overloading (which in turn is probably very important for templated generic code): otherwise code with overloaded operators would require dereferences/taking address-of at every step, not looking like operator usage with built-in types at all.

Another thing is that a reference cannot be made to reference a different object, unlike pointers. So this may give the compiler some guarantees, which may allow it to optimize better...

Quote:

Since your pointer is only storing an address(and so will be a constant size of something like 4 bytes), but your reference will be as big as the object, which could be far more.


The reference itself doesn't have a size (or has the same size as a pointer if you look at implementation details): it reports the size of the referenced object, as it pretends to be the referenced object in every other way.

Share this post


Link to post
Share on other sites
Quote:
Original post by Winegums
Another question I had (but forgot to ask) is is there a performance benefit to using pointers as opposed to references when dealing with large objects? Since your pointer is only storing an address(and so will be a constant size of something like 4 bytes), but your reference will be as big as the object, which could be far more.

No. The reference is as big as the object because it "is the object" *wink wink*, not because it entails copying the object around.

Share this post


Link to post
Share on other sites
Quote:
Original post by Sneftel
No. The reference is as big as the object because it "is the object" *wink wink*, not because it entails copying the object around.


I nominate this post for the "Best use of *wink wink* in a technical discussion" category [smile]

Share this post


Link to post
Share on other sites
Quote:
Original post by Winegums
Pointers store an address, and objects store some data, but do references store some sort of pointer-like object that says "go to that guy over there"? (as opposed to pointers which say "go to address 0x...")

The implementation most likely stores a pointer, yes. But from the pure language POV, you cannot access that pointer.

Quote:
Original post by Winegums
I can see that they're the same size as the object they alias (which makes sense, since they're an alias).

How do you see that? The following code

LargeObject o;
LargeObject& r = o;
std::cout << sizeof o << std::endl;
std::cout << sizeof r << std::endl;

prints the size of o twice, because there is no way to get any information about r itself. The standard doesn't even define if r has a value.

Under certain contrived circumstances like this one, the compiler might be able to optimize the reference away completely. Read the Stroustrup, it's all in there ;)

OMG I have been Ninja'd very severely. Well, this is what the Stroustrup says:
Quote:

The obvious implementation of a reference is as a (constant) pointer that is dereferenced each time it is used. It doesn't do much harm thinking about references that way, as long as one remembers that a reference isn't an object that can be manipulated the way a pointer is.
In some cases, the compiler can optimize away a reference so that there is no object representing the reference at run-time.

Share this post


Link to post
Share on other sites
Quote:
Original post by Winegums
Vs Pointers
- Garunteed to be an object (as opposed to a pointer which can be NULL)


... or invalid, or pointing implicitly to an array of objects rather than a single object.

Share this post


Link to post
Share on other sites
Quote:
Original post by Zahlman
or pointing implicitly to an array of objects rather than a single object

Hm...

int a[100];
int& r = *a;

;-)

Share this post


Link to post
Share on other sites
Exactly what is the problem with that? An array decays to a pointer to the first element. You dereference it and take a reference to that. Now you can manipulate the first item in the array as one would expect...

What you could do is reference an item out of bounds:

int array[10];
int& ref = *(array + 100);


So there's plenty of ways to get invalid references in C++.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!