Printable View
Hello Everyone.
Just wondering, why would you use pointers (ie. Find the memory address of a variable etc)? Also, is there any chance that memory addresses change after (say...) closing the program and then restarting your computer, then reopening the program?
Thanks.
Pointers allow you to "point" functions and methods to a value that is stored in memory. Unlike passing a value only, the functions and methods can use the pointer to alter the memory at that location. There are many possible uses of pointers--both clever and dangerous--that I am sure other members could give you better examples than I could.
Restarting the program will change the literal address of where data is stored, but usually not the offset. Meaning that the data in memory is usually a fixed distance from where the program was entered into memory (somone correct me if I am wrong on this).
Pointers have many uses. They can be used to pass objects by address in functions to avoid copying, they allow polymorphism, they allow dynamic memory allocation (on which are based all STL containers and such), they allow you to make callback functions, etc.
Thanks guys :).
i remember after first reading about pointers, i thought too it was used to "find the memory address" of a variable or function. i also was confused about why this is so popular or even how to use it in practice. however, the purpose of pointers is not really to "find the memory address" from a high-level / human point of view--that is, do you or i care about the actual hexadecimal address that some variable in a program is stored in? no. however, it is important that the computer knows where to find a variable or function.
here are 2 important uses of pointers:
1) variable-sized arrays
- lets say we write a phone-book program. at compile-time, the compiler (nor do we or the computer) does not know how many people we are going to add into our phone book program. we could define the array structure that stores the phone book entries to be of size 20 to be safe. however, what if we only use 2 entries? there is wasted space. what if we want to enter 100 entries? there is not enough space.
- a dynamic array is used instead of a array of static/constant size 20. we can resize the array at run-time as needed, and doing it this way (can) ensures minimal to zero wasted space, and that we can always add more entries, or make the array larger.
- see "malloc" for C and "new" for C++
2) pass-by-reference
- lets say we have some math program that has a 100 by 100 matrix of integers. we also have a function to search a given matrix for the value at a specific row-column pair. if the function used "pass-by-value" for the matrix parameter, it would involve (the computer automatically) making a copy of the 100*100*(size of integer, usually 4 bytes)=40000 byte matrix so it can be used in the function, then forgotten about after the search function has returned.
- thankfully, "by default", arrays and pointers are "passed-by-reference", where only a copy of the fixed-size pointer argument is passed, rather than the actual data structure.
- all primitive data types are passed by value, unless "told" otherwise. these are things such as char, int, float, etc.
once you start, if you havent already, really digging into the language and writing some programs, you will find the need for pointers and be thankful. so the best way to learn, is to do!
Thanks.
I don't really understand though, why use a pointer?
Say for example, this script:
Why don't you just use int nMyInt = 10; rather than using a pointer?Code:int nMyInt = 0;
int* nMyPointer = &nMyInt;
nMyPointer = 10;
I'm actually finding pointers quite fun to learn haha. :P
Thanks :D,
Sorry if I'm confusing hehe.
in my last post i tried to explain something similar to your example. i.e., we dont really care about the address of some variable; use pointers when needed. in your code, there is no reason to use a pointer. it would depend on the context (what is later done with the variable).
Aaah okay thanks :).Quote:
Originally Posted by nadroj
lets look at an example function:this function returns 1/true if the given number number is even, and 0/false otherwise. what if some program we are using expects all numbers it uses to be even? we can modify this function so that if the given number is odd, we can make it even, and "return" that new even number as well as whether the original number was even or odd (say our program has a counter of how many "original" numbers were actually even vs. odd; i know silly).Code:int isEven(int x)
{
if ( x % 2 == 0 )
return 1;
else
return 0;
}
we can change our function to use pass by reference:
again, somewhat of a silly program i know, but i hope it helps you understand. when this function is called, the actual variable is not passed from the calling function, but a pointer to the memory address of where the variable is. because of this, any changes made to the variable (via the pointer) in the isEven function, effect the original variable (since it is modifying the same memory address).Code:int isEven(int &x)
{
if ( x % 2 == 0 )
return 1;
else
{
// x is odd, so lets make it even
x++;
// x is now even
// the important thing is that since x was passed by reference, the original variable is also changed, i.e. the one in the "int main()" function or
// whoever else called this function.
// this is important because, in our example, the program/main() expects to only work with even numbers.
return 0; // however we still need to return 0/false/"odd number" to the calling function who is keeping a count of how many even vs. odd
}
}
But the function isn't really performing an "isEven" kind of task now. It's altering its input. The name of the function needs to be changed, perhaps to "makeEven", since that's what it's doing.Quote:
Originally Posted by nadroj
well you are correct, for odd numbers. if the number is even it doesnt alter it correct? it doesnt make sense to call it "makeEven" in that case. anyways, i think this is up to debate, and a design question. since it does both check polarity of the number and make it even if it is odd, there are two logical names for the function, or maybe a combination of the two should be used.Quote:
Originally Posted by brewbuck
i think it is a subjective issue.
They're useful in games, for example, pointing to the high score.
Please let this be a joke.Quote:
Originally Posted by michaelp
:|Quote:
Originally Posted by EVOEx
I'll be quiet.
But they are useful in games.
Wow -- you've devised a function who's name depends on the inputs passed to it. I think you've invented an entirely new programming paradigm.Quote:
Originally Posted by nadroj
Not really.Quote:
i think it is a subjective issue.
"not really" by itself is a subjective answer.Quote:
Originally Posted by brewbuck
the functions purpose is to check if a number is even or not, the parameter x has postcondition that it will be even.
Then the function's purpose is clearly not to "check if a number is even or not." Its purpose is to ENSURE the number is even.Quote:
Originally Posted by nadroj
Remind me not to have you write any code for me...
dont worry i wont :)
again, the functions purpose is obvious. a required side effect or postcondition is that the parameter x is even after the function has returned.
anyways, we arent being constructive and this is doing no good to this thread or forum.
I think the advice to name functions appropriate to their purpose does a great deal of good in general.Quote:
Originally Posted by nadroj
i agree (though ive never heard of that design paradigm before!).
from the start, i said it was a silly example, but i just thought of something quick and on the spot to give the thread starter an example. if this were a real-world application, of course the function and postcondition would be documented in detail, so the design team doesnt assume anything incorrectly. it is possible the thread starter isnt even reading this thread anymore, however you or anyone of course can always give them different or better examples to help their understanding.
lots of reasons. consider if you had an object whose data is used and represented in many different places. using a pointer to that object's data prevents you from having to update the values at each of the other locations.Quote:
Originally Posted by sharkbate24
also, if you have a large object, assigning or passing it by value requires you to make a copy of that object which can be quite resource-intensive. a pointer is the same size as an int.
judicious use of pointers can make your code more efficient, reliable, and reduce the total amount of work you have to do.
yes, they will change.Quote:
Originally Posted by sharkbate24
There would be a third, though it is related to the first: for the implementation of data structures that involve "links" of some sort, e.g., linked lists and trees. Also, the second is not as important in C++ due to the existence of reference types, even though C++ references are themselves typically implemented as const pointers.Quote:
Originally Posted by nadroj
Actually, only arrays are "passed by reference" due to them decaying to a pointer to their first element, since the pointers themselves are passed by value.Quote:
Originally Posted by nadroj
I am so happy to report that you are wrong!Quote:
Originally Posted by nadroj
Since we are discussing C++, they are passed by pointer or by address, not reference.
4 good reasons (most already stated) for using pointers (and/or references):
- Dynamic memory (not so common in C++; usually std::vector is used).
- Allow other functions to modify local variables (if they are not passed by pointer/reference, copies are made and thus the original values are not changed).
- Avoid overhead of copying data (only the pointer would be duplicated).
- Allow several places in the program to see the same data and be able to update it and make the changes reflect everywhere this data is used.
Look carefully at the quotes. We are talking about the computer science term, not the C++ term.Quote:
Originally Posted by Elysia
Well, this is C++, so pass-by-reference means using references. There I object to the term. I always have and this is even a better reason to object it. Avoids confusion.
We will not have this discussion again.
We will not.
This thread is full of hate.