Printable View
i was told that it tells P to point on the data which on the address "abc"Code:string t="rrrrr";
string *p=&t;
strcpy(p, "abc");
i thought that in order to change the address of a pointer we need to add &
strcpy(&p, "abc");
???
(i know that changing the address into "abc" is not recommended)
You can't change the address of a pointer (or of any variable). Once you declare the variable, it's address is firmly set, once and forever.
You can, however, change the value of a pointer, just as easily as you can change the value of an int: x = 10 or p = &t.
Your example has nothing to do with changing the address. Plus string is not defined in C (just in C++)
All that's doing is placing the character string "abc" in an array of byte cells whose starting location is contained in the variable &p.Quote:
Originally Posted by transgalactic2
A pointer has an address like other variables (which can't and needn't be changed) but what makes a pointer a pointer is that it's value is an address -- the address of the variable it points to (which means this address has to be a different one; *ptr=&ptr won't work).
A confusing thing about c is the difference between the syntax referencing int's and char's. Probably this is because char declarations (eg, char word[]="this") are usually arrays for strings, so you are allowed to initialize them using a "string constant" ("this") AND refer to that constant using the name of the array. With an int, the name of an array defaults to pointing to it's first element (I'll explain why at the end). Look at this:
the outputCode:#include <stdio.h>
int main () {
int intray[5]={'t','h','i','s','\0'};
char charray[5]={'t','h','i','s','\0'};
printf("using intray: %s\n", intray);
printf("using charray: %s\n", charray);
}
using intray: t
using charray: this
So strcpy(&p, "abc"); is something you can't (and would never need to) do.
The "&" gives you the address of a variable, the same address a pointer to that variable would hold. It's usually used with single integer variables and char array names so that those variables can be passed to a function and modified without having to be returned or globalized.
Of course the output is 5. That's because we passed the function a "pointer" (&x, the address of x). So in examplfunc, &x is *n, a pointer to some number. That means we can change the value at the address directly, rather that having to return a value for assignment. With a char array (which is more common) it looks different:Code:#include <stdio.h>
void exampfunc (int *n) {
*n=5;
}
int main () {
int x=0;
exampfunc(&x);
printf("%d\n",x);
}
No & and only one *, but the output is still that.Code:#include <stdio.h>
#include <string.h>
void exampfunc (char *n) {
strcpy(n,"that");
}
int main () {
char word[]="this";
exampfunc(word);
printf("%s\n",word);
}
string t="rrrrr";
You can't work strings this way in C. You have to think of them as char arrays. When you declare a char pointer (char *word) you can use strcpy on it after you assign it some memory, since you actually need multiple memory addresses to store multiple letters -- but the pointer *word will include all the spaces assigned to it. Since you don't assign int's memory, their pointer's only cover the first value of an array.
So to conclude: strcpy(&p, "abc"); is impossible because "abc" requires an array. You can't reference anything but a character array, and for that you can't use "&".
That might work, depending on what ptr points to (if it points to an int, then hurray! if it points to a char, then boo!). ptr=&ptr will always work (leaving out architecture issues, should anyone be using a computer where different pointers have different sizes).Quote:
Originally Posted by MK27
There are no syntax difference between int's and char's. Yes, people often throw around char * and char[] as strings, but there's no syntax here.Quote:
Originally Posted by mk27
This is simply untrue. The name of an array (no matter what base type) always and forever defaults to a pointer to its first element (NOT the value of its first element). (Except in sizeof, but that's a keyword and not an evaluation context.)Quote:
Originally Posted by mk27
All this example shows is that you have a little-endian system. If you had a big-endian system, intray would have printed nothing at all! The "reason" you can't print an integer array as though it were a string like this is that sizeof(int) != 1, so 't' in an int array takes up two/four/eight bytes (one/three/seven of which are zero, which act in a string context as null terminators). And on a little-endian system, you'll find the significant bits (where the zeroes are) last.Quote:
Originally Posted by mk27
Note that the proper integer code that pairs with your character code isQuote:
Originally Posted by mk27
Note again no & and one *.Code:void exampfunc(int *n) {
n[2] = 7;
}
int main() {
int numbers[] = {1, 2, 3, 4, 5};
exampfunc(numbers);
printf("%d\n", numbers[2]);
return 0;
}
I like nearly all of this. (The end worries me a tad; a pointer's just a pointer, but we know we own the memory behind it, so I guess it's ok.)Quote:
Originally Posted by mk27
Eh. See above.Quote:
Originally Posted by mk27
Oh Yes There Is!Quote:
Originally Posted by tabstop
Now, if you change 7 to 'X' you can change &cptr to *cptr (and %c to %d), and then it looks the same because both are 88. But after you do that, try changing the first %d to %c and *iptr to &iptr. If that worked, you'd have a transparently symmetrical relationship in the syntax.Code:#include <stdio.h>
#include <string.h>
int main () {
int y=7, *iptr=&y;
char x='X', *cptr=&x;
printf("%d %c\n",*iptr,&cptr);
}
You're right, and I changed the text of the orginal post to read "defaults to pointing to".Quote:
Originally Posted by tabstop
I don't think you're actually disagreeing with me -- could be a matter of syntax.Quote:
Originally Posted by tabstop
What?Quote:
Originally Posted by MK27
Running the original gives me
7 p
Changing 7 to 'X' and &cptr to *cptr gives me
88 88
Making the second set of changes (both to &) gives me
x p
I fail to see how "printing a 32-bit pointer as though it was an 8-bit character screws things up" translates into "ints and chars have different array syntax".
I did this:
and got X X like I would expect.Code:int main () {
int y='X', *iptr=&y;
char x='X', *cptr=&x;
printf("%c %c\n",*iptr,*cptr);
}
I fail to see how it doesn't, which is what I demonstrated. If you run the example with &iptr over again, you'll notice the value changes because &iptr is still just an address. You're final example is exaclty the same as the first change -- the one I said "makes it look the same". You could also consider their syntax the same because they both use a single syllable abbreviation, which is true. You can't prove your point with positive examples -- you have to demonstrate there are any contrary ones, so please ignoreQuote:
Originally Posted by tabstop
printf("%c %c", &iptr, &cptr);
Your point was, as I recall, that you can "refer [to the value of the string] using the name of the array". I say (paraphrasing) that's baloney, because the name of the array always is a pointer to the first element of an array (regardless of whether it is an array of char or of int). So in this code
name, by itself, does not refer to "Babalu". name, by itself, does not refer to 'B'. It refers to 0xwhatever, the address in memory where the first element of the name array is stored. If you print it with %c, as inCode:char name[10] = "Babalu";
you won't get 'B' (unless you are very lucky).Code:printf("%c", name);
And (which was my point) everything I just said would be equally true if it was int name[10].
You can refer the value of a string using the name of an array, because the name is a pointer to a chunk of memory of an allocated size containing the string!
And my point was there's a syntax difference, which is why my first example for transgalactic didn't read:
Maybe this is symptomatic of how "printing a 32-bit pointer as though it was an 8-bit character screws things up".Code:int intray[5]="this";
char charray[5]="this";
Ah, I see. There is a difference when you initialize them, yes. I foolishly took your statement about referencing arrays to mean referencing arrays.
this is a quote from an article:
"
int foo;
int *foo_ptr = &foo;
Now, how do you assign an int to this pointer? This solution might be obvious:
foo_ptr = 42;
It is also wrong.
Any direct assignment to a pointer variable will change the address in the variable, not the value at that address. "
here its been said that i can change the address of a pointer
???
No, you can't change the address of a pointer (look again!).
It says you can change the address in the variable.
A pointer simply holds a memory address, so of course you can change that.
But you cannot change the address of a variable (the address where the variable is located).
Unless you specifically know how or why to do otherwise, you shouldn't even ever directly set a pointer to a constant value other than zero.
so (foo_ptr = 42 ; ) will change the address of the variable foo but the value of foo
will stay the same
but i thought that
&foo_ptr represents the address of foo
why arent they doing
??Code:&foo_ptr = 42;
The return value of &foo_ptr is an rvalue; it cannot legally appear on the left hand side of an assignment.
so we can use &foo_ptr only to print it or use this address as a static value
but not to change the address
but if we want to change the address of "foo" variable
we do
thanksCode:foo_ptr = 42; //for example
No. As Elysia has noted, "you cannot change the address of a variable".Quote:
but if we want to change the address of "foo" variable
It would be a bit like you going out on the street and starting to change the numbers on the house... Once you live in a particular house, you can't just change it's number [I'm sure the local government can, but that is something else] - and a variable is located by the "local government", which is this case is the combination of compiler and operating system (the compiler being your "local government", and the OS being the "central government" for the entire system - the compiler still needs to abide by the OS's rules).Quote:
Originally Posted by laserlight
--
Mats
ok so if i cant change any address what so ever then
what does this value 42 change in this line
??Code:foo_ptr = 42;
It changes the value of foo_ptr. In other words, foo_ptr no longer points to foo (since foo is still at 123598736), but points over there somewhere.
Edit: 123598736 is a random number.
It changes the value of foo_ptr, though more accurately you would write:Quote:
what does this value 42 change in this line
But now, attempting to dereference foo_ptr probably leads to undefined behaviour.Code:foo_ptr = (int*)42;
so the pointer foo_ptr will point on address 42 ??
The pointer foo_ptr will contain the address 42. But why would you want to do that?Quote:
so the pointer foo_ptr will point on address 42 ?
That is to say, the odds of address 42 actually existing and belonging to your program are small.
i cant understand this form of casting you are doing here:
you want to present the number 42 as an integer and put it into foo_ptr
but why you add* (i suppose it has something to do with pointer)
but i cant see what this line mean:
unlikeCode:foo_ptr = (int*)42;
Code:foo_ptr = (int)42; //without *
??
It's the compiler's job to associate the symbol foo with a memory location so the behaviour is undefined if you try to relocate it to another place or it could become a foobar :D
Because foo_ptr is not an int, so casting to an int is bad and ..., well, bad. foo_ptr is an int *, so the value you assign to it should also be an int *.
It's the compiler's job to associate the symbol foo with a memory location so the behaviour is undefined if you try to relocate it to another place or it could become a foobar :D
thanks
It's the compiler's job to associate the symbol foo with a memory location so the behaviour is undefined if you try to relocate it to another place or it could become a foobar :D
Think of this:
You declare two variables. One variable of int and one variable of a pointer to int. You have allocated two memory spaces (thus variables). Each memory space that holds the variables has a fixed memory address. Lets say [0x111] and [0x112] respectively.Code:int a;
int* p;
Now, you cannot change this memory addresses. Whatever you do a will be at [0x111] and p at [0x112]. Now lets do this:
Your memory will look like this:Code:a = 5;
p = 6;
So the memory address 0x111 is variable a. This are the same in a way.Code:[0x111] = 5 (variable a)
[0x112] = 6 (variable p)
[0x113] = something (a memory location not used yet)
...
[0x200] = something (a memory location not used yet)
Now, lets do this:
Now you will have:Code:p = &a;
Because the memory address of a is 0x111. That value you assign to p. That is all.Code:[0x111] = 5 (variable a)
[0x112] = 0x111 (variable p)
[0x113] = something (a memory location not used yet)
...
[0x200] = something (a memory location not used yet)
Now if you do this:
Then lets say c goes to [0x113]. Now c will have the value of where p points to. That means it will have the value of the variable that is stored in the value of p.Code:int c;
c = *p;
Which means in our example that c will have the value of the memory location [0x111] because p has the value of 0x111. That memory location (which is effectively variable a) has the value 5. So c will have the value 5 assign to it. So:
Finally, you can do this:Code:[0x111] = 5 (variable a)
[0x112] = 0x111 (variable p)
[0x113] = 5 (variable c)
...
[0x200] = something (a memory location not used yet)
You will have this:Code:p = 0x200;
Whats wrong with that? If you do this:Code:[0x111] = 5 (variable a)
[0x112] = 0x200 (variable p)
[0x113] = 5 (variable c)
...
[0x200] = something (a memory location not used yet)
then you will assign to c the value that is on the memory address [0x200] which is not a variable used by the program. It is not allocated. So it cannot be used (at least with safety) and you have no idea what it's value.Code:c = *p;
Final note. The address 0x111,... are chosen by the program! You have not control on where the variables will be stored!
A pointer has an address. It also contains and address, and using the dereferencing operator, you can access the value stored at the address that the pointer contains. You can also modify the address the pointer contains, but modifying the address of the pointer is not possible because it's simply decided by the operating system where it's located.
A pointer can point to itself, and modify itself, although this will most likely cause issues. I am not sure you can actually modify a pointer 4 bytes at a time, that is beyond the scope of my knowledge of the inner workings of the operating systems I used(Anyone who can elaborate?) but I know for a fact that a pointer can modify itself, but if you write one byte to it, you must consider that the address contained in the pointer will also change, meaning that any subsequent writes will be completely fubar'd.
Yes you can modify a pointer which points to itself 4 bytes at a time.
Output:Code:void *pnt;
pnt = &pnt;
printf("%i %ld\n", &pnt, (long)pnt);
*(long *)pnt = 1;
printf("%i %ld\n", &pnt, (long)pnt);
1309944 1309944
1309944 1
Your mileage may vary.
(Ouch, this hurt my brain.)
Alright, cool. I was just wondering if the operating system did in fact have the hardware capabilities to actually write more than one byte each time. But it makes sense that it can, since I guess the latter would be insanely inefficient.Quote:
Originally Posted by nonoob
Depending on your rig, there are registers capable of writing up to 16bytes simultaneously.
No, I want (or rather, you want, for reasons I cannot fathom) to "present" the number 42 as an address and store that address in foo_ptr. Remember, a pointer is not an (ordinary) integer. A pointer is an address.Quote:
Originally Posted by transgalactic2
I guess by now, and I am certain I am probably not the first to have asked this during the course of this thread. But why would you want to do this in the first place? What possible advantage can come of this practice?
thanks
this question was out of personal curiosity
I'm not quite sure you understand.Quote:
Originally Posted by IceDane
Since the beginning of time the hardware chips could do 1, 2, 4, 8, 10 bytes at a time (if you remember 80-bit internal floating-point registers on math coprocessors). Some of the MMX and further graphics register extensions can do more, as was pointed out.
I guess it begs the question as to the atomicity of internal operations. Do addresses get evaluated over the time interval they are changing? Surely flipping 64 bits takes some finite amount of time. I would suggest that what's really going on is that there are temporary latches, holding registers, whose contents get promoted to other registers... then written back. These things happen within the time resolution (clock), and thus are not subject to partial re-evaluation at any sub-time level.
Actually, I would see changing a house's as trying to uproot a house and move it to a new address ;)Quote:
Originally Posted by matsp
And if that house is a variable, then you can understand why it's just not possible/feasible to change its address.
Btw, c_ntua, nice demonstration of how pointer work :)
I'm going to bookmark it.
Thanks.Quote:
Originally Posted by nonoob
And no, to be perfectly honest I very, very limited knowledge of how this works on the hardware level. I'll have to look into that. Just not sure what to search for / where to start, but thanks for the explanation.