Printable View
Code:char a[] = "Tennisstar"; // this works
char *a = "Tennisstar"; // this also works
/*but a pointer is a variable that stores a mem. add. and an array is a
group of varibles... how how are they same?
Why doesn't it work with integers?
Why in int arrays you have to specify a number between the square brackets (size) but not in char?*/
/*and yes... all nerds out there
please explain in simple terms since i am a beginner...
THANX!!!*/
You mean this doesn't work?
Code:int array[] = { 1, 2, 3, 4 };
They are not the same.When you have a array ,you can not move the pointer ,which points to the array, but you can modify the contents.When you have a char pointer, you can not modify the content , but you can move the pointer.Quote:
Originally Posted by tennisstar
Example
Code:#include <iostream>
using namespace std;
int main()
{
char a[] = "Tennisstar";
char *b = "Tennisstar";
char *c = "SAMARAS";
a[6]='W';
b = c;
b[6] = 'W'; /* Error */
a = c; /* Error */
cout<<"a is "<<a<<endl;
cout<<"b is "<<b<<endl;
cout<<"c is "<<c<<endl;
return 0;
}
...Quote:
Originally Posted by tennisstar
PS - Learn how to use string.If you posted in the right thread and you want to learn C++.
This explanation is kind of poor. Array types are not pointer types, so it is best to avoid explaining them with the word pointer. In fact, if you use the word pointer you probably failed.Quote:
Originally Posted by std10093
Array types are collections of variables. They are not l-values themselves. If you try to use an array in an l-value context, this will be apparent because there is nowhere to store any relevant changes.
The "arrays decay to pointer to the first element" rule pretty much dominate the acceptable uses, except when you use sizeof, &, or a string literal used to initialize an array.Code:int main()
{
int bar[4];
int array[4];
array = bar;
++array;
array -= 2;
return 0;
}
#if 0
In function 'main':
Line 5: error: incompatible types in assignment
Line 6: error: invalid lvalue in increment
Line 7: error: invalid operands to binary -
#endif
whiteflags, yes i agree that i could explain it better.
But remember that
v is a pointer to first element of array ;)Code:int v[5];
The compiler disagrees with you. The type of v is in fact int[5] unless you use it in a pointer context.
No, it is not. As whiteflags said, v is an array of 5 ints.Quote:
Originally Posted by std10093
Names of arrays can be treated as if they are pointers, in some contexts. That does not mean an array is a pointer. There are contexts where the difference is readily apparent.
If you look through this forum (and any other forum concerned with C or C++) you will find numerous questions asked because folks have incorrectly believed that arrays are pointers, only to experience surprising (to them) effects caused by the fact that pointers and arrays are distinct things.
I think this example will make clear the difference between a pointer and an array..
Code:char charr[]="This";
char *chptr="This";
printf("%u",&charr);//This will print starting address of string "This". charr takes no space to get store.
printf("%u",&chptr);// This will print the address of pointer chptr while this is not starting from there and it's taking space 4byte in gcc to store address..
Not true, doha.
Firstly, printing out addresses using the %u format causes undefined behaviour.
Second (even tying on the blindfolds and ignoring the undefined behaviour) your comments do not really reflect what is happening.
See... char[] works because it is an array of char variables but how can char* work because it is not an array of chars but it is a pointer which can store the memory address of a variable with the datatype char... that is what i wanted to know...
and yes.. by "Why doesn't it work for int?" i meant why cant you do int* a = 1213 like that... and why can you do it to char like char* a = "tennisstar"
thanx in advance...
Since you are confused about how pointers can point to strings I recommend reading:
Question 1.32
I take it for granted that why people choose to use pointers to strings instead of making arrays is less confusing to you. A lot of the reason for using pointers to strings comes from planning ahead: if you aren't going to be editing a debugging string, then there is little sense in using arrays which are editable when there is a more restrictive choice available in pointers.
That does have a meaning. Well, it did, but C++ explicitly disallows it. Initializing/Assigning an integer to a pointer would change its value in the C language.Quote:
i meant why cant you do int* a = 1213
But let's go deeper. As for why you can point pointers at strings and not do the same for integer arrays, well it just takes a bit of thinking. With strings it should be obvious that each letter maps to a location, or group of locations, as Unicode encodings may force you to do, in a string. Programming languages are human inventions and we are used to communicating in text within everyday life. Applying this experience to numbers is significantly harder. 1213 in that context could mean this or a number of other combos:
If the compiler is going to work, it has to know what your intention is for the array that is being assigned. And that's pretty much all I can say on the topic. It took a few edits to get there.Code:int *a = { 1, 2, 1, 3 };
or
int *a = {12, 13};
or even
int *a = {1213};
Ah. You're asking about the infamous anomaly of C.Quote:
Originally Posted by tennisstar
Firstly, it doesn't make sense to do "int *a = 1213" any more than it makes sense to do "char *c = ' '" (note the single quotes in the char example). Both are invalid, and will cause a compiler to complain, for the same reason. It makes no sense to convert an int value (1213) into a pointer, and also makes no sense to convert a char value (' ', which is 32 with the ASCII character set) into a pointer.
But, to come to your question, the handling of char strings to initialise char pointers is actually a historical anomaly in the language. Originally, in early versions of C (I'm not sure if this predated K&R C, or was originally part of K&R C) it was never valid to initialise a pointer using an array.
At that time, these constructs were valid
but these constructs were not validCode:int ai[] = {1,2,3};
int *pi = i; /* equivalent to int *pi = &ai[0] */
char ac[] = "xy"; /* equivalent to char ac[] = {'x', 'y', '\0'} */
char *pc = c;
This is how it was, and compilers were shipped. Programmers, if they wanted a pointer that was initialised so it contained the first address of a char literal, were forced to doCode:int *pi = {1,2,3};
char *pc = "xy";
A few too many programmers at the time were zealots of terse code, so they thought it made sense to doCode:char *ac[] = "xy";
char *pc = ac;
/* code that uses pc but never again references ac */
and their compilers complained bitterly about this. Those programmers then lobbied their compiler vendors to allow this to happen. However, the same programmers caused some bemusement for their compiler vendors by insisting thatCode:char *pc = "xy";
/* code that uses pc */
should still be invalid.Code:int *pi = {1,2,3};
Hence, today, we have an anomaly in the C language. Character pointers can be initialised directly using a string literal, but pointers to other types cannot be initialised using an array initialiser.
The reason for this anomaly is purely non-technical. In fact, it was quite political, and the arguments in favour of the anomaly often amounted to religious fervour (from those who worship at the altar of terseness).
Hey all...
its me tennisstar...
while i was programming today... i came up to this assumption...
(note: this is just an assumption and i just wanna figure out if i was right...)
Code://when i do:
char a[11] = "Tennisstar"; // the extra 1 for the /0 character
// it works because a is an array of chars....
char *b = "Tennisstar";
// also works and i'm trying to figure out how
char *c = new char[256]
//works because it points to an array of chars...
/*So my assumption is that when you create a char* and assign it a value like "Tennisstar" it assumes that
your pointer points to an array of chars*/
/*I just wanna know if i'm right or wrong
if right i'll relax
if wrong i'll continue the hunt for my answer
*/
//THANKYOU everyone in advance
Pretty much.Quote:
/*So my assumption is that when you create a char* and assign it a value like "Tennisstar" it assumes that
your pointer points to an array of chars*/
I used %u so it's easy to manipulate.Quote:
Originally Posted by grumpy
Can u please explain the meaning of "undefined behaviour"?
Let me make clear what i m trying to say in comments:Quote:
Second (even tying on the blindfolds and ignoring the undefined behaviour) your comments do not really reflect what is happening.
1. This printf statement will print the address of char 'T' of string "This" and variable 'charr' will be stored in symbol table to link it when variable is used.
2. In this when chptr will be used it will bind the address where address of string "this" is stored. and chptr will take 4 byte to store the starting address of "this".
Now if still it's wrong then make me correct..
Your preference for decimal is showing.Quote:
I used %u so it's easy to manipulate.
The short answer: there is a format %p that you are supposed to use to print an address. Consequently, no other format needs to be implemented so that it works.Quote:
Can u please explain the meaning of "undefined behaviour"?
Longer answer: One thing that makes %u wrong is that you are assuming the unsigned integer type and the pointer type will always be the same size. You are also assuming that pointer types are all the same size. Many implementations are accommodating because the assumptions you make are true on your home computer, running 32-bit code. Neither of these things are guaranteed to be true so your results will be suspect on platforms different from your home computer. Your choice of integer format is also completely arbitrary. Nothing makes %u more suitable than %d for replacing the proper choice, %p.
You are not even printing what the comments say you are printing. You are printing the addresses of the location of the pointers themselves instead of the pointers' values. Printing the pointers' values looks like this:Quote:
1. This printf statement will print the address of char 'T' of string "This" and variable 'charr' will be stored in symbol table to link it when variable is used.
2. In this when chptr will be used it will bind the address where address of string "this" is stored. and chptr will take 4 byte to store the starting address of "this".
There are also things that make no sense whatsoever in your comments. What is being passed to printf is a pointer char* cast to void* so that will take up stack space in the printf function. The initial values of the array charr, and the literal string used to initialize chptr are also stored somewhere, so that will take up space. And finally, gcc -- along with any compiler -- does not allocate memory for any program. The OS is in charge of that, when the program is executing.Code:#include <stdio.h>
int main(void)
{
char charr[]="This";
char *chptr="This";
printf("%p\n", (void*)charr);
printf("%p\n", (void*)chptr);
return 0;
}
In simple terms, it means your code can do anything. It might produce the results you intend. It might reformat your hard drive. Any results you can imagine are permitted because the C++ standard says (in effect) "anything that happens is permitted".Quote:
Originally Posted by dojha00
I'm happy to let you make things clear. When do you plan to do so?Quote:
Originally Posted by dojha00
Sorry, but you're including a bunch of extraneous information that is not really relevant to what the code is doing. And the relevant parts of what you say are incomplete.
Both of your printf() statements yield undefined behaviour, because you are using "%u" to print out pointers. No more needs to be said. Once code has undefined behaviour, it is pointless saying anything else about it. Because, short of changing the code, there is no way to make the behaviour defined.Quote:
Originally Posted by dojha00
Even if you corrected that (using %p to print out pointers as whiteflags suggested, rather than %u, assuming your compiler supports the 1999 C standard or later) then you need to understand that pointers have two attributes: value (which might be printed like an address using the %p format) and type.
In your code, &charr has type "pointer to array of 5 char". It therefore cannot point at a single char although its value, if you print it out, will be the same value you'd get by printing out the address of the 'T' (i.e. the value is the same, the type is different). Similarly, &chptr has type "pointer to pointer".
Your observation about variable charr stored in symbol table is compiler specific at best, and irrelevant to describing what the code does. Similarly, your observation that "chptr" will take 4 byte ..." is not guaranteed (different compilers will make chptr different sizes) and is also not relevant to describing what the code does.
Thanks grumpy and whiteflags for making me more clear about using %u and %p for printing addresses.
Btw when i talk about size, i thought about gcc 32-bit compiler(gcc version 4.6.3) which i have described in my comments written inside program and for making it easy to understand i did not focus on type of pointer(which has become an important issue now).
Suppose if i m not casting it to void* then from where will it take place (heap??)?Quote:
What is being passed to printf is a pointer char* cast to void* so that will take up stack space in the printf function.
If u can provide me some more useful link about this then it will be better ...
Btw i m trying to google it and know more..
No matter what type it is the pointer will be passed to printf so it will take up space. Just like any other data you pass in to printf will take up stack space.Quote:
Suppose if i m not casting it to void* then from where will it take place (heap??)?
Printf implementations at some point have to use a C feature called variable argument lists: Variable Argument Lists in C and C++ - Cprogramming.com