const char ca[] = {'h','e','l','l','o'};
const char *cp = ca;
// printf("%s\n",cp);
while(*cp) {
cout << *cp << endl;
++cp;
}
first it print:
h
e
l
l
o
// end
then I uncomment "printf" statement:
hello%s
h
e
l
l
o
%
s
// end
Why are the results so different?,how does the "While" condition exit(the exact value of *cp)?
C++ primer 5th page 110
while(*cp)
This loop condition is looping until it finds a NUL character. It's equivalent to:
while(*cp != '\0')
ca isn't NUL-terminated, so the loop runs off the end of the array and invokes undefined behavior. Undefined behavior means anything can happen.†
To fix this, add a NUL terminator with
const char ca[] = {'h','e','l','l','o','\0'};
or, equivalently,
const char ca[] = "hello";
† It appears that in the first case the loop ends right away because there happens to be a NUL byte in memory following the 'o'. But in the second case the "%s" string happens to be adjacent to ca and so that gets printed, too. "%s" is a proper NUL-terminated, so the loop ends after printing it.
The fact that an innocuous printf() call can change the behavior of an unrelated loop is an example of how unpredictable undefined behavior can be. It isn't always so benign. It could make your program crash. It could even make it continue working for a while and then misbehave later in a completely baffling way. Don't rely on undefined behavior behaving predictably.
Related
I was playing around with c strings in c++ and found some behavior I don't understand when I don't terminate a char array.
char strA[2] = {'a','\0'};
char strB[1] = {'b'};
cout << strA << strB;
I would expect this to print ab, but instead it prints aba. If I instead declare strB before strA, it works as expected. Could someone explain what's going on here?
This is undefined behaviour and you simply are lucky that replacing the declaration of these 2 arrays works for you. Let's see what is happening in your code:
char strA[2] = {'a','\0'};
Creates an array that can be treated like a string - it is null terminated.
char strB[1] = {'b'};
Creates an array that cannot be treated like a string, because it lacks the null terminating character '\0'.
std::cout << strA << strB;
The first part, being << strA, works fine. It prints a since strA is treated as a const char*, which provided as an argument for std::ostream& operator << will be used to print every character untill the null terminating character is encountered.
What happens then? Then, the << strB is being executed (actually what happens here is a little different and more complicated than simply dividing this line into two, separate std::cout << calls, but it does not matter here). It is also treated as a const char*, which is expected to ended with mentioned '\0', however it is not...
What does that lead to? You are lucky enough that there randomly is only 1 character before (again - random) '\0' in memory, which stops the (possibly near-infinite) printing process.
Why, if I instead declare strB before strA, it works as expected?
That is because you were lucky enough that the compiler decided to declare your strA just after the strB, thus, when printing the strB, it prints everything that it consists + prints strA, which ends with null terminating character. This is not guaranteed. Avoid using char[] to represent and print strings. Use std::string instead, which takes care of the null terminating character for you.
When printing char arrays, the C (and C++) convention is to print all bytes until a '\0'.
Because of how the local variables are organized, strB's memory is behind strA's, so when printing strB the printing just 'overflows' and keeps printing strA until the terminating '\0'.
I guess when the deceleration is reversed, the printing of strB is terminated by a 0 that is just there because nothing else was set there, but you shouldn't rely on that - this is called a garbage value.
Don't use unterminated C-strings, at all. Also avoid C-strings in general, you can use C++ std::string which are much more secure and fun.
When I run this code on my computer, I have a bunch (exactly seven) of weird chars printed between the ab to the a, which are probably whatever was between strA's and strB's memory spaces.
When I reverse the declarations, I get ab$%^& where $%^& are a bunch of weird chars - the ones between the end of strB's memory to the next random \0.
I'm pretty inexperienced in c++, and I wrote the following code to see how characters and strings work.
#include "stdio.h"
#include <iostream>
#include <string>
using namespace std;
int main()
{
char asdf[] = "hello";
char test[5] = {'h','e','l','l','o'};
cout << test;
}
I was expected it to output "hello", but instead I got "hellohello", which is really puzzling to me. I did some experimenting:
If I change the asdf to another string of a different length, it outputs "hello" normally.
If I change the amount of characters in test it outputs "hello" normally.
I thought this only happened when the two were the same length, but when I change them both to "hell" it seems to output "hell" normally.
To make things more confusing, when I asked a friend to run this code on their computer, it outputted "hello" and then a random character.
I'm running a fresh install of code blocks on Ubuntu. Anyone have any idea what is going on here?
This is undefined behaviour.
Raw char* or char[] strings in C and C++ must be NULL-terminated. That is, the string needs to end with a '\0' character. Your test[5] does not do that, so the function printing the output continues after the last o, because it is still looking for the NULL-termination.
Due to how the strings are stored on the stack (the stack usually grows towards lower addresses), the next bytes it encounters are those of asdf[], to which you assigned "hello". This is how the memory layout actually looks like, the arrow indicates the direction in which memory addresses (think pointers) increase:
---->
+-------------------
|hellohello\0 ...
+-------------------
\_ asdf
\_ test
Now in C++ and C, string literals like "hello" are NULL-terminated implicitly, so the compiler writes a hidden '\0' behind the end of the string. The output function continues to print the contents of asdf char-by-char until it reaches that hidden '\0' and then it stops.
If you were to remove the asdf, you would likely see a bit of garbage after the first hello and then a segmentation fault. But this is undefined behaviour, because you are reading out of the bounds of the test array. This also explains why it behaves differently on different systems: for example, some compilers may decide to lay out the variables in a different order on the stack, so that on your friends system, test is actually lower on the stack (remember, lower on the stack means at a higher address):
---->
+-------------------
|hello\0hello ...
+-------------------
\_ test
\_ asdf
Now when you print the contents of test, it will print hello char-by-char, then continue reading the memory until a \0 is found. The contents of ... are highly specific to architecture and runtime used, possibly even phase of the moon and time of day (not entirely serious), so that on your friends machine it prints a "random" character and stops then.
You can fix this by adding a '\0' or 0 to your test array (you will need to change the size to 6). However, using const char test[] = "hello"; is the sanest way to solve this.
You have to terminate your test array with an ascii 0 char. What happens now is that in memory it is adjacent to your asdf string, so since test isn't terminated, the << will just continue until it meets the ascii 0 at the end of asdf.
In case you wonder: When filling asdf, this ascii 0 is added automatically.
The reason for this is that C style strings need the null character to mark the end of the string.
As you have not put this into the array test it will just keep printing characters until it finds one. In you case the array asdf happens to follow test in memory - but this cannot be guaranteed.
Instead change the code to this:
char test[] = {'h','e','l','l','o', 0};
cout is printing all characters starting from the beginning of the given address (test here, or &test[0] in equivalent notation) up to the point where it finds a null terminator. As you haven't put a null terminator into the test array it will continue to print until it accidently finds one in memory. Up from this point it's pretty much undefined behavior what happens.
Last character should be '\0' to indicate end of string.
char test[6] = {'h','e','l','l','o','\0'};
Unless there is an overload of operator<< for a reference to an array of 5 chars, the array will "decay" to a pointer to char and treated as a C style string by the operator. C style strings are by convention terminated with a 0 char, which your array is lacking. Therefore the operator continues outputting the bytes in memory, interpreting them as printable chars. It just so happens that on the stack, the two arrays were adjacent so that the operator ran into asdf's memory area, outputting those chars and finally encountering the implicit 0 char which is at the end of "hello". If you omit the other declaration it's likely that your program will crash, namely if the next 0 byte comes later than the memory boundary of your program.
It is undefined behavior to access memory outside an object (here: test) through a pointer to that object.
Character sequences need a null terminator (\0).
char asdf[] = "hello"; // OK: String literals have '\0' appended at the end
char test[5] = {'h','e','l','l','o'}; // Oops, not null terminated. UB
Corrected:
char test[6] = {'h','e','l','l','o','\0'}; // OK
// ^ ^^^^
I have the following simple code:
#include<iostream>
const char str[]={'C','+','+'};
int main()
{
const char *cp=str;
std::cout<<*str<<std::endl;
while (*cp++>0)
std::cout<<*cp;
}
can't understand why it prints
C
++
Shouldn't the postfix increment operator evaluate the expression but return the value unchanged? (I double checked precedence of increment, dereference and relational operators and it should work)
This line prints: C and the carriage return.
std::cout<<*str<<std::endl;
Then you are looping on following characters but there is no ending character (c.f. buffer overflow)
Here's the code fixed up.
#include <iostream>
const char str[]={'C','+','+', '\0'};
int main()
{
const char* cp = str;
std::cout<< *str << std::endl;
while (*cp++ > 0)
std::cout << *cp;
return 0;
}
This code is even simpler if you want to display "C++"
#include <iostream>
const char str[]={'C','+','+', '\0'};
int main()
{
const char* cp = str;
while (*cp > 0)
std::cout << *cp++;
std::cout << std::endl;
return 0;
}
Your problem is here:
while (*cp++>0)
std::cout<<*cp;
The postfix operator increments the value after the expression it was used in is evaluated. There are two different expressions referring to cp in this while statement though: the first one tests and increments, but the second one prints. Since the second one is a separate statement, the increment has already happened by then.
i.e. you currently test against 'C', then increment regardless of the result, then print '+' through the now-incremented pointer. If it were iterating a string literal, this code would also increment once after reaching the 0, although you don't see a result of that because it skips the print (because it iterates over a hand-created array with no null terminator, what it actually does here is fall off the end and exhibit undefined behaviour; this is a big error in itself, you can't rely on there being a zero at the end if one wasn't put there).
shouldn't the postfix increment operator evaluate the expression but return the value unchanged?
No, postfix operator returns the value of operand first then, only it is increased by 1.
here,
while (*cp++>0)
std::cout<<*cp;
by the time it reaches std::cout<<*cp; the value of cp is incremented, and hence the result ++.
In the line
while(*cp++>0)
The post increment operator is executed, after the evaluation happens.
i.e. cp points to C during the first evaluation of the while condition.
So,
*cp => 'C' which is greater than 0.
Before moving to the next line (Inside the loop), the post increment operator gets executed, making cp point to the first +
After + is printed, the while condition is executed again, this time *cp returns '+'. since '+' > 0, the control enters the loop for the second time.
Before entering the loop, the post increment operator executes again, making cp point to the second '+', which is printed.
Now, while condition is executed for the third time. Here, *cp returns +. Thus, control enters the loop again.
Before entering the loop, post increment executes again. This time, it makes cp point to the next character, which is \0.
The \0 is printed, which makes no difference in this code. Then, when the while condition executes again, *cp returns \0, which is not > 0. So, the condition fails.
Edit: Saw in the comments that you wanted to print the entire String in the same line. Change the loop to:
while(*cp > 0)
std:cout<<*cp++;
I got this code from a textbook:
#include <iostream>
using namespace std;
int main(){
char str1[]="hello,world!", str2[20], *p1, *p2;
p1=str1; p2=str2;
/*
for(;*p1!='\0';p1++,p2++){
cout<<"p1="<<*p1<<endl;
*p2=*p1;cout<<"p2="<<*p2<<endl;
}
*p2='\0';
p1=str1; p2=str2;
*/
cout<<"p1="<<p1<<endl;
cout<< "p2="<<p2<<endl;
return 0;
}
I ran this code, it will output p1=hello,world!p2=
which I can understand.
But if I uncomment the for loop, the output shows here I got confused, why after the for loop, why it shows p1= instead of showing p1=hello,world!, and for pointer p2, even after the assignment in the for loop, it still shows p2=?
But after I uncomment p1=str1; p2=str2; this line, the output is p1=hello,world!, p2=hello,world!, why it works like that?
And what's the reason for writing this line *p2='\0';, it doesn't matter that this line is commented out or not, the previous outputs don't change.
can anyone tell me how the char pointer here is working?
The loop modifies p1 so that it points to the null terminator at the end of the string. That's the definition of an empty string. p2 likewise points to a null terminator at the end of a string.
If you reset p1 and p2 to their original values you can see the strings as they are.
The code is for copying str1 to str2.
In C++, '\0' is used to end a string. When you try to print a char pointer (say ptr), the compiler prints the string starting from *ptr (the character pointed to by the pointer). When the compiler finds '\0', it stops printing.
In the beginning, p1 points to the first char of str1 and p2 points to the first char of str2. If you print them without doing anything else, the compiler will print both the strings out completely. So the output will be p1=hello,world!p2=.
The for loop makes p1 and p2 advance through str1 and str2. At the end, p1 points to the \0 at the end of the str1 and p2 points to the '\0' at the end of str2. So if you print p1 or p2 directly after the for loop ends, the compiler will immediately find '\0' and stop printing. So, you get the output p1=p2=.
Uncommenting p1=str1; p2=str2; will make both strings point to the first characters again, so printing them now will cause the whole string to be printed. So you get the output p1=hello,world!p2=hello,world! (because str1 got copied to str2 in the for loop).
The *p2 = '\0' is just for ending str2 with '\0'. If your code works without that line, it means that the compiler initialized all the characters of str2 to '\0' automatically. However, the compiler isn't guaranteed to do that, so you should always terminate strings with '\0' in your programs.
Here is the output I see from VS2010 running that code with the commented parts uncommented:
p1=h
p2=h
p1=e
p2=e
p1=l
p2=l
p1=l
p2=l
p1=o
p2=o
p1=,
p2=,
p1=w
p2=w
p1=o
p2=o
p1=r
p2=r
p1=l
p2=l
p1=d
p2=d
p1=!
p2=!
p1=hello,world!
p2=hello,world!
That's pretty much what I would have expected! Basically this code is copying the contents of str1 into the (uninitialised) char array str2 via direct pointer manipulation, by copying each character from str1 into str2 one at a time.
To answer your last question, the reason for
*p2='\0';
is so that the second string that is being "created" by the for loop will be correctly null terminated. Without that line, it will just be a char array that cannot be treated like a 'C' string.
Overall this is a pretty contrived / non robust example though, as it won't work once we exceed 20 characters in length for the first string, due to str2[] being declared to be only 20 chars in size.
A c++ string is a char * under the hood, p1 and p2 are both pointing to the same string, as they are incremented they go through the characters of the string "*p2='\0';" sets the string to the null character it has no effect on the program because it is being reset anyway in the line after.
This is trivial, probably silly, but I need to understand what state cout is left in after you try to print the contents of a character pointer initialized to '\0' (or 0). Take a look at the following snippet:
const char* str;
str = 0; // or str = '\0';
cout << str << endl;
cout << "Welcome" << endl;
On the code snippet above, line 4 wont print "Welcome" to the console after the attempt to print str on line 3. Is there some behavior I should be aware of? If I substitute line 1-3 with cout << '\0' << endl; the message "Welcome" on the following line will be successfully printed to the console.
NOTE: Line 4 just silently fails to print. No warning or error message or anything (at least not using MinGW(g++) compiler). It spewed an exception when I compiled the same code using MS cl compiler.
EDIT: To dispel the notion that the code fails only when you assign str to '\0', I modified the code to assign to 0 - which was previously commented
If you insert a const char* value to a standard stream (basic_ostream<>), it is required that it not be null. Since str is null you violate this requirement and the behavior is undefined.
The relevant paragraph in the standard is at §27.7.3.6.4/3.
The reason it works with '\0' directly is because '\0' is a char, so no requirements are broken. However, Potatoswatter has convinced me that printing this character out is effectively implementation-defined, so what you see might not quite be what you want (that is, perform your own checks!).
Don't use '\0' when the value in question isn't a "character"
(terminator for a null terminated string or other). That is, I think,
the source of your confusion. Something like:
char const* str = "\0";
std::cout << str << std::endl;
is fine, where str points to a string which contains a '\0' (in this
case, two '\0'). Something like:
char const* str = NULL;
std::cout << str << std::endl;
is undefined behavior; anything can happen.
For historical reasons (dating back to C), '\0' and 0 will convert
implicitly to any pointer type, resulting in a null pointer.
A char* that points to a null character is simply a zero-length string. No harm in printing that.
But a char* whose value is null is a different story. Trying to print that would mean dereferencing a null pointer, which is undefined behavior. A crash is likely.
Assigning '\0' to a pointer isn't really correct, by the way, even if it happens to work: you're assigning a character value to a pointer variable. Use 0 or NULL, or nullptr in C++11, when assigning to a pointer.
Just regarding the cout << '\0' part…
"Terminating the string" of a file or stream in text mode has an undefined effect on its contents. The C++ standard defers to the C standard on matters of text semantics (C++11 27.9.1.1/2), and C is pretty draconian (C99 §7.19.2/2):
Data read in from a text stream will necessarily compare equal to the data that were earlier written out to that stream only if: the data consist only of printing characters and the control characters horizontal tab and new-line; no new-line character is immediately preceded by space characters; and the last character is a new-line character.
Since '\0' is a control character and cout is a text stream, the resulting output may not read as you wrote it.
Take a look at this example:
http://ideone.com/8MHGH
The main problem you have is that str is pointer to a char not a char, so you should assign it to a string: str = "\0";
When you assign it to char, it remains 0 and then the fail bit of cout becomes true and you can no longer print to it. Here is another example where this is fixed:
http://ideone.com/c4LPh