Tom's Guide | Tom's Hardware | Tom's Games
 |
 |
 |
#include
#includeint main()
{ char* charPtr="see me";
printf("%s\n", charPtr);
printf("%d", charPtr);
return 0;
}
-------
I do not understand the line:
char* charPtr="see me";
1)Is this mean that "see me" will get stuck in to memory?
2)What is the meaning of *charPtr? nothing?
First, #2
The meaning of *charPtr is ambiguous (my big word for the day) unless it's in context.
In this context, char *charPtr, this declares the variable named charPtr to be a pointer to a character. So, charPtr is a variable that holds a pointer (a memory address) and the data located at that memory address will be interpreted as a character. A 'character'?? Hold that question for a moment.
#1char *charPtr = "see me";
tells the compiler to:
1-allocate a variable named charPtr whose data type is 'pointer to char'
2-allocate 7 bytes of memory and initialize that memory to the string "see me" (including the ending NULL)
3-initialize the value of the charPtr variable to the address of the first byte of the memory allocated in step 2 (the byte containing the 's'
Regarding the printf statements.
In both cases, the value contained in the charPtr variable is passed as a parameter to the printf statement to be output. The difference between the two statements is how the format string indicates that this value should be output.
The first statement (with the %s) is instructed to print the string that is found at the memory address that is passed in.
The second statement (with the %d) is instructed to take the received value and print it as an integer. So what you are getting is the actual memory address of the 's' from the string "see me".
In both cases, the same value is being passed in. The difference is what the printf does with the received value.
Regarding the 'pointing to a character' issue. A char* points only to one character. The printf("%s.... works because the definition of %s is that it should output the characters found at the starting address and keep outputting the following characters until a NULL is found. That's why if you somehow don't have a NULL, you'll get garbage because the printf keeps printing everything it finds (many times 'unprintable' stuff) until it finds a null.Try these two things:
printf("%c\n", charPtr);
Why did you get only an 's' as output? Because the definition of %c in printf is to output only the character found at the received memory address.
++charPtr;
printf("%s\n", charPtr);You should see the string "ee me"
The ++ told the compiler to increment the value contained in charPtr by (1 times the sizeof the data type being pointed to).
Since a char is only 1 byte, the address was incremented by one. Try:
printf("%d\n", charPtr);
You should note that the value is 1 bigger than before.
This is probably going into more than you want to know at this point, but to better see an example of 'pointer arithmetic', change 'char *charPtr' to 'int *charPtr' (yes, the name no longer makes sense, but you won't have to change other parts of the program.Now after you do ++charPtr with a printf("%d\n",charPtr) before and after, you'll notice that the value output changed by either 2 or 4. Why? Because pointer math works in increments of (1 times the size of the datatype pointed at).
So, ++charPtr increment by whatever number of bytes it takes to hold an integer on your machine (most likely four). This helps in array processing (another subject).
0 
Actually in this case the pointer is to
charptr[0], and the behavior of assigning
static strings to unalloced pointers is
implementation and compiler specific.
Though you can get away with it,
why bother?
You can't free the memory and that's the
only reason not to use something like:
char charbuf[7] = {"see me"};My .02 cents.
0
Not sure about your point in saying "the pointer is to charptr[0]".
Isn't that the same as saying "initialize the value of the charPtr variable to the address of the first byte of the memory allocated", which I said in item 2 of how the compiler is implementing the statement in question? The pointer is pointing to the first byte of the allocated memory.
I've never run into a compiler that wouldn't handle the statement listed. It wouldn't surprise me if there are, but it's not the norm.
So, if you can get away with it, why not?
Yes, it's good to know that you can't free the memory, but in many cases who cares?
0
I wasn't criticizing your analysis Don.
I can tell that you are a very experienced programmer.
I was just clarifying it for the OP and
also letting him know that there is a st-
andard way of doing things like this.If you don't care about freeing memory then use static allocation.
NOT char *ptr = "unfreeable string";
If you don't care about memory leaks they'll
care about you ;)
0
I wouldn't consider that a memory leak. A memory leak is when the amount of memory used by a program continues to grow the longer the program runs, because memory is being allocated over and over without being freed. This memory is allocated once and never again.
It could be considered wasted memory because it's going to stay allocated longer than necessary.
It most cases that's not a problem, tho it should be something to be aware of.
I guess that doing things differently is what makes the world go round.
0
JT
Are you saying that there is a difference between
char *ptr = "string";
and
char ptr[7] = "string";
??
0
There couldn't be a difference because no usercall to malloc was made if it's a legal
declaration, so it would be compiler alloced
transparently. How and from where you or I don't know, depending on compiler and platform.My point is that it's probably not good practice.
I know that when I first started I wondered
why when this worked:
char *ptr = "this and that";This would segfault.
char *retString(void) {
char *ptr;
printf("Enter your string: ");
fgets(ptr,45,stdin);
return ptr;
}My reasoning was thus.
If char *ptr = "string";
and char[7] = "string";
are equivalent declarations(they are not IMO),Why would this work but the first not?char *retString(void) {
char ptr[45];
printf("Enter your string: ");
fgets(ptr,45,stdin);
return ptr;
}Of course with a little more experience the answer why it doesn't work is obvious.
But it was a bad habit to get into and caused me more trouble than it should have.
0
> Are you saying that there is a difference between
char *ptr = "string";
and
char ptr[7] = "string";
??There most definitely IS a difference. As I found out when writing my compiler for my college compiler class. It took me 8 hours of debugging to finally figure out that the compiler implements them differently.
Try this:
char *ptr1 = "string";
char ptr2[] = "string";
char *test;test = ptr1;
test = ptr2;Have your compiler generate assembly code and look at the differences.
0
JT
I started to explain why
char *ptr = "string";
and
char ptr[7] = "string";
are so close to the same thing that the differences aren't important, but after typing for 30 minutes I remembered more details that meant rewriting the explanation, but didn't change the conclusion, so I gave up (it's 1am for me and I have other stuff to do before bed).
But I assure you, that the first declaration (with char*) does actually have memory allocated by the compiler. And is functionally equivelant to the second declaration (char ptr[]).
If you are interested in the details, email me and I'll put an explanation on a website I'm building and let you know when it's ready. But you are making a couple of conclusions that are not correct. The good news is that your incorrect conclusions will not cause you any problems. They are keeping you from doing things that are OK, but not causing you to do any bad things.
0
Yes, they are different when you start paying attention to what kind of variables are allocated and where in memory they are located, etc.
What started this is that JT implied that
char *ptr = "see me";
was bad code and that
char ptr[7] = "see me";
was barely better and that a allocation routine should be used to allocate the string (at least that's how I understood what he said).
My point is that in the context of writing a program and getting it to run successfully, it doesn't matter which one you use and it's perfectly valid to use either and it's basically a waste of effort to use a malloc/calloc to allocate the memory for these type strings (which is what I understood JT to be saying was necessary for as a 'good programmming practice').
0
No Don, that's not what I meant.
I meant to say that whether or not
char *str and char str[7] are functionally
equivalent is out of your control.If you get used to saying char *ptr
points to the same amount of memory
char ptr[7] does when you assign a character
array to each this leads to problems in the future when you have to deal with dynamic allocation.
0
I'd never make a blanket statement that char *ptr points to the same amount of memory as char ptr[7]. In this example they were pointing to the same thing tho.
In many cases char* and char array are interchangeable if you understand the details.
If you truly understand the details of each (char *, char[], dynamic allocation), then you don't have to let one confuse the other.
I've had advantages that many haven't, I'll admit. Out of college I worked in assembler, then learned C in an environment where we had to pay attention to how and where things were allocated, then I taught C and Advance C classes. So between the assembler, low level code background and the teaching, I've had a lot of opportunity to learn the details.
0  |
 |
 |
This post is quite old and has been locked from receiving new replies. Please create a new posting instead.
| Ads by Google |
