pointer assignment- when to use '&'

this is valid in the book i'm reading:

int *p,num;
p = &num

so is this:

int *i, j[10];
double *f, g[10];
i=j;
f=g;

both accomplish basically the same thing right (though obviously in the second example an array is used)?
Last edited on



both accomplish basically the same thing right?


Not at all. One time you declare an int and an int*, and then let the int* point to the int. The next time you declare 2 int* and 2 int arrays, and let each of the int* point to one of the arrays.
closed account (1vRz3TCk)
both accomplish basically the same thing right

in your case they are both/all pointers-to-an-integer, it is just how they are assigned that is different. So yes they accomplish the same thing , that of assigning a value to a pointers-to-an-integer.

Same here:
1
2
3
4
5
6
int num;
int arr[10];
int * int_ptr;

int_ptr = #  // points to num
int_ptr = arr;   // points to the first int in the array 


Last edited on
ok, so

1. '&' is not necessary when assigning to an unindexed array or string, but is necessary with just a regular int?

2. if i changed the 3rd and 4th lines in the second example in my OP to

i=j[3];
f=g[5];

would that still work, or would i then need a '&' because i'm assigning the address of an INT, though it's part of a larger array?
closed account (1vRz3TCk)
1
2
3
4
5
6
int arr[10];
int * int_ptr;

int_ptr = arr;     // arr is automatically converted to a pointer
int_ptr = arr[1];  // Error: arr[1] is an int that can not be automatically converted to a pointer
int_ptr = &arr[1]; // OK: takes the address it the second element of the array 
Last edited on
codemonkey, do line 6 of your first post and line 4 of your most recent contradict each other?
Last edited on
closed account (1vRz3TCk)
codemonkey, do line 6 of your first post and line 4 of your most recent contradict each other?

no. arr is automatically converted to a pointer to the first element of the array

edit:
let me elucidate, the comments in the first one are mean to be read as "int_ptr now points to..."

Last edited on
huh. so now that line DOES NOT assign the location of the first integer in arr[x] to pointer int_ptr? like it did in your previous example? sorry, i guess i'm just having a tough time with this.

Last edited on
Those lines do not contradict, they mean exactly the same thing erik.
sorry, i meant the comments (appear to me to) contradict
It's just that in C/C++ an anything foo[ANY_SIZE]; Is always automatically cast to a anything *bar; whenever needed. And then bar points to the first element in the array (bar+1 to the second element, etc).
closed account (1vRz3TCk)
sorry, i guess i'm just having a tough time with this.
I don't blame you, pointers can be a pain to get your head around.

OK, try this
A pointer holds the address of an object. When you prefix an object with an ampersand (&object), you are effectively saying you want the address of the object not the object itself.

When you have an array of objects and you refer to it only by name you are given the address of the first element of the array. So with int_ptr = arr;, int_ptr wants an address and arr is converted to the address of the first element so all is good.

When you subscript the array (use []) you are asking for the object so you need to prefix it with the an ampersand to get the address of the element at that position. int_ptr = &arr[1];

Is that any clearer, or am I just muddying the water?
i understand most of this. the only thing i'm having a tough time with is:

say for example i initialized a character string and corresponding pointer like this:

char str[20]="This is the string.";
char *p;

at this point, referencing the unindexed string like this:

cout<<str;

would output the following:

This is the string.


now you're saying that if i then went on to assign the pointer like this:

p=str;

p is assigned the memory location of str[0] ('T')-- right, i understand.


but you're saying that, also the variable str is converted to a pointer type and now contains the memory location of the old str string?

so now cout<<str; will no longer display "This is the string.", it will display a memory location, "0e12FE5c", for example, or something like that?

can i even still access the string after that? or has the entire str string undergone some sort of type conversion?

this is so weird
Last edited on
ok, well i plugged it into the compiler, so i know cout<<str; will still display "This is the string."

but now i'm more confused than ever as cout<<p; also displays "This is the string.", and not the memory location of str[0], like i thought it should.
Last edited on
That's because cout "knows" what to do with a char* (actually it's an operator overload, you'll get to that later).

If you'd cast it to void* or int you'd get the memory address instead.

1
2
3
cout<<"the string: "<<str<<endl<<
      "its memory address (void*): "<<(void*)str<<endl<<
      "its memory addres (int): "<<(int)str<<endl;


Also, when we say "converted" we don't mean that str itself is actually changed, but rather that the value that is copied from str to p is not a char array, but a char*.
Last edited on
this is getting reaaaalllly annoying.

i'm reading the pointer page of the C++ tutorial on THIS VERY SITE. in the "Pointer initialization" section, it says to initialize a pointer for a character constant like this:

char *terry="hello";

it claims this gives terry the value of the memory location of the 'h' in "hello".

not only is this not the case, but that line won't even compile in Dev C++. i get the error "invalid conversion from const char to char"... wtf?

it will only compile if i subscript terry with brackets, in which case the value of terry becomes "hello", not the memory address of the constant.
You need to declare that char* as "const" because string literals are always constant.

 
const char *terry="hello";

(if the tutorial actual says this without the const modifier it needs an update)

terry's value IS the memory location of h in hello. You can check this with
 
cout<<*terry; //h 


I already told you in my previous post - cout has a special way of handling char*, so it will always try to interpret char* as a string.

Also, DevC++ is evil.
Last edited on
so the value of 'terry' is not what i will actually see when i type "cout<<terry;", strictly on account of the way cout handles the character pointer?
Pretty much, yes. cout interprets a char* always as "a array of chars" and will print the value the char* points to and all values after that until it hits a \0 character.
Last edited on
ok cool.
my world is spinning a little less now, thanks. :)
Topic archived. No new replies allowed.