Printable View
for example
int& func(int& a);
i keep seeing it in my book and it assumes you already know what it does, so it must be something basic. What does it do?
edit:
Quote:
ahh, crap, i actually already understood the pass by reference idea, i just got it mixed up with the return type syntax. sorry about that.
let me ask a different question:
what type of variable is returned with a int& return type?
you said it was returning a reference but not a pointer?
It's returning a reference to an int, instead of a direct int or a pointer to an int.
what do you mean by reference? isn't a pointer a reference?Quote:
Originally Posted by MacGyver
A reference is an actual name for something in C++, not a generic term (at least in this case). A reference type is denoted with the & and is in many ways similar to a pointer (but in many ways it is different). If you haven't learned references yet, skip ahead to the chapter on them and read up to get the basic idea, or get a book that explains them better before it uses them.
Yes, in a generic sense. No, in a pedantic C++ sense.Quote:
Originally Posted by thracian
A reference in C++ is a special type of variable that acts as a pointer under the hood.
For example:
If you ran this code, you'll get 5, even though the var it has is incremented. The reason is that a copy of x is really given to inc(), not x itself. This means that inc() is playing with a temporary variable and not changing anything back in main().Code:#include <iostream>
void inc(int a);
void inc(int a)
{
a++;
}
int main()
{
int x = 5;
inc(x);
std::cout << "x = " << x << std::endl;
return 0;
}
If you changed the code so inc() took a reference, then that means the output would be 6, because a reference binds a particular variable to another one. In that case, inc() would be playing with the same variable x.
References are really implemented as pointers, however, that is hidden from you as a programmer. You let the compiler worry about the details.
References are safer in the sense that you can't receive a NULL pointer. You know automatically the reference refers to some variable. It can be a little tricky since there is no way to tell if a function is passing by reference or passing by value if you just look at a function call without seeing the function prototype.
ahh, crap, i actually already understood the pass by reference idea, i just got it mixed up with the return type syntax. sorry about that.
let me ask a different question:
what type of variable is returned with a int& return type?
you said it was returning a reference but not a pointer?
A reference is an actual thing. It is like a pointer in that you add a symbol to the type to indicate that you want the variable to be a reference to that type, but it is a completely separate thing in C++.
Code:int* this_function_returns_a_pointer_to_int();
Code:int& this_function_returns_a_reference_to_int();
This example might help you see what int & would be returning.
The output isCode:int& func(int &a)
{
return a;
}
int main()
{
int *a = new int(1);
int *t;
t = &(func(*a));
*a = 10;
cout<<"Value of t: "<<*t<<endl
<<"Value of a: "<<*a<<endl;
delete a;
return 0;
}
The behavior of references made more sense to me once I started messing around with pointers. Since "a" and "t" are both integer pointers, what effectively happened is func() made the pointer "t" point to the same memory that "a" is pointing to.Code:Value of t: 10
Value of a: 10
If "a" and "t" are NOT pointers, the code will be modified like this
And the output will beCode:#include<iostream>
using namespace std;
int& func(int &a)
{
return a;
}
int main()
{
int a = 1;
int t;
t = func(a);
a = 10;
cout<<"Value of t: "<<t<<endl
<<"Value of a: "<<a<<endl;
return 0;
}
In this case, IMO, it's pointless to have function return by reference. However, if you are working on embedded software, writing a kernel, or device driver the memory saving might be worth the strange looking function.Code:Value of t: 1
Value of a: 10
HTH
pantherse - I understand that when you pass by reference, you're passing the memory location instead of the copy of the value.Code:#include <iostream>
using namespace std;
int& func(int a){ return a;}
int main(){
int x =1;
cout <<"&x: "<<&x<<endl
<<"func(x): "<< func(x)<<endl
<<"&func(x): "<<&func(x);
system("pause");
return 0;
}
Can you explain that code though?
output:
&x: some address
func(x): 4469696
&func(x): some different address
i'm just trying to understand what kind of value is returned with a reference return type. why is it different?
The code you posted is wrong thracian, and different than pantherse's code. In your code, the parameter to func is an int, but in pantherse's code it is a reference to int.
The reason this matters is because func then returns a reference to that variable. So in pantherse's code, a refers to x and so the func function returns a reference to x. In your code, a is a copy of x, so the func function returns a reference to that copy. But the copy is destroyed when the function ends and so it returns a reference to a destroyed variable. This causes undefined behavior, meaning you can't really figure out anything from what happens because the code is wrong.
Try it again with:Code:int& func(int& a){ return a;}
There are instances in my book where the reference operator follows the return type and not the arguement type which is the source of this confusion.Quote:
Originally Posted by Daved
Yes, and it is allowed in some instances depending on the reference refers to. However, here you are returning a reference to the argument, so when that argument is a plain int it will be destroyed.
Returning a reference to a local variable is wrong. Any valid example that returns a reference is returning something other than a local variable. So you can't look at your example because it just isn't valid C++.
An important thing to understand is object lifetime. A local variable (like the parameter in your example) is destroyed at the end of its block of code. You can't use a reference or pointer to a destroyed variable.
So with my example is the reference some random memory location or where the destroyed variable used to exist? If it's where it used to exist, why isn't func(x)=1?Quote:
Originally Posted by Daved
It's undefined behavior. Anything can happen. On my machine it is 1 because it probably does just return the location that the variable used to have. Perhaps your compiler is clearing out the data in that memory location or is pointing to a random memory location. It shouldn't really matter, though, because it's invalid code. It might change behavior the next time you change it or the next time you compile it or the next time you run it.
I'd be delighted to explain the code. However, this is going to be a long-winded answer because I'm going into under-the-hood stuff.Quote:
Originally Posted by thracian
&x prints the memory location for variable x, which in this case contains the value 1.
should have printed "1", which is the value of x that was passed to func() but it didn't. What happened is that the execution of func() completed and returned the memory address that "a" used to occupy. However, before the value was printed your kernel decided that it'll put your program on hold, and let another process run. For whatever reason, the kernel gave the memory address that func() returned to that process who wrote something else in the same location. So instead of you getting 1 in your output you got whatever that value was.Code:<<"func(x): "<< func(x)<<endl
In fact, gcc compiler 4.2.3 (which I used to compile the code you posted) generated the following warning
The lineCode:test2.cpp:5: warning: reference to local variable ‘a’ returned
actually prints out the memory address of func()'s return value. In this case it's the memory address of "a"Code:<<"&func(x): "<<&func(x)
Other languages like ADA, FORTAN, or Java won't let you get away with these kind of stuff, I personally consider the sample code you gave as sloppy. However, there's a reason why the language allows it. If you are writing an OS kernel or device driver, to name a few, you need to have this flexibility. But if you do this you're basically on your own. The common cause of most software security issues is because of mishandling memory using a language that'll let you do whatever you feel like (even write assembly code as part of your C/C++ code).
Ah, thanks guys.
That's not true (not for modern operating systems anyway).Quote:
Originally Posted by pantherse
Why? Because Virtual Memory separates memory for each process. That means the kernel CAN'T give away the memory location in your program to some other program. The other program writes somewhere else.
Stop here, and go back to your book.Quote:
Originally Posted by thracian
Elysia, you are correct. However, it is still possible for a Virtual Memory location to be in one physical location one second, and be relocated by the OS the next. I can get back to you once I get home if you want more details. I don't have my OS theory book on me.Quote:
Originally Posted by Elysia
Sure, that happens all the time, but the application itself still can't give that memory to any other application (unless it is asking the OS nicely to share it between the two apps).Quote:
Originally Posted by pantherse
Also, if the OS swaps the physical location of the memory, it's the OS's responsibility to make sure that the page being swapped is not being used at the exact moment it is being replaced. So the contents of a memory page should (assuming the OS is bug-free) always be consistent with what the application can expect. So if a value is written to a particular memory location, and the physical memory is being relocated or some such, the same value should be found in the same virtual location after the relocation is done. This is of course tricky stuff, and doing such operations require good understanding of what the machine does, and understanding what processes are able to access such a page, and ensuring that any process that may be accessing that memory is blocked (not running), or things will go (very horribly) wrong in a hurry.
So whether the memory is being "moved" or not, it should have it's content valid whenever the memory is available (if it's not immediately available, the application will cause a page-fault, and the PF handler will block the process, fix up the page so it has it's valid content before making the process runnable again).
--
Mats
Ok, so now I'm the one who has a question: In the case of the sample code, the variable "a" has been deallocated since func() has already gone out of scope. The OS doesn't have to necessarily guarantee the content of that memory location correct?Quote:
Sure, that happens all the time, but the application itself still can't give that memory to any other application (unless it is asking the OS nicely to share it between the two apps).
Also, if the OS swaps the physical location of the memory, it's the OS's responsibility to make sure that the page being swapped is not being used at the exact moment it is being replaced. So the contents of a memory page should (assuming the OS is bug-free) always be consistent with what the application can expect. So if a value is written to a particular memory location, and the physical memory is being relocated or some such, the same value should be found in the same virtual location after the relocation is done. This is of course tricky stuff, and doing such operations require good understanding of what the machine does, and understanding what processes are able to access such a page, and ensuring that any process that may be accessing that memory is blocked (not running), or things will go (very horribly) wrong in a hurry.
So whether the memory is being "moved" or not, it should have it's content valid whenever the memory is available (if it's not immediately available, the application will cause a page-fault, and the PF handler will block the process, fix up the page so it has it's valid content before making the process runnable again).
A local variable lives on the stack. It is unlikely (although not ENTIRELY impossible) that the OS will deallocate the stack - in which case you would get a page-fault for it being unavailable when it's returned from the function - and if the OS decided that the stack is no longer neede there [unless the stack is grown in an official way, such as calling a function again], then the application would just crash. I do not know of any OS that deallocates the stack after it has shrunk - it will swap it out to disk after it has been out of use for some time, but not deallocate it.
The more likely scenario is that the same area of stack is used by another function, which overwrites the location returned by func(), and the stack content is now something completely different - so the value of "the reference to a" will change at random[1], possibly many times if you call different functions (or the same function with different values). That is because the memory location on the stack that held a whilst in the function, gets re-used for whatever purpose the code wants to use it for when you call those other functions - and that may change if you compile the code with a different compiler or even different compiler switches.
[1] Not random like a random number generator, but random in relation to what you may expect by just looking at the function itself if you didn't realize it was returning a reference to a local variable that will go out of scope.
--
Mats
A likely scenario might be:
However, when we take the following:Code:int* foo()
{
int x = 0;
return &x;
}
int main()
{
int* x = foo();
cout << *x << endl; // It's likely the value is still intact here.
}
We see that "y" overwrites the data stored in the local variable x inside foo.Code:int* foo()
{
int x = 0;
return &x;
}
int main()
{
int* x = foo();
int y = 1000;
cout << *x << endl; // You'll probably see 1000 here, instead of 0.
cout << y << endl;
}
This is not guaranteed and should not be relied upon in any sort of way.