I wrote this code in C++, and I used getchar() to puase the console, but I did not see any effect of using that function, here is the code:
#include<iostream>
#include<stdio.h>//to pause console screen
using namespace std;
//function prototypes
int getSmallest(int*);
int getOccurrence(int, int*);
int main(){
int a[7], counter=0, smallest;
cout<<"Please enter 7 integers"<<endl;
while(counter!=7){
cin>>a[counter];
counter++;
}
smallest=getSmallest(a);
cout<<"The smallest number is "<<smallest<<"; it apears "<<getOccurrence(smallest,a)<<" times"<<endl;
getchar();//to pause console screen
return 0;
}
int getSmallest(int*x){
int count=0, smallest=*x;
//loop till last item in array
while(count!=7){
if(*x<smallest)
smallest=*x;
count++;
x++;
}
return smallest;
}
int getOccurrence(int smallest, int* address){
int count=0,occ=0;
//loop till last item in array
while(count!=7){
if(*address==smallest)
occ++;
count++;
address++;
}
return occ;
}
As has been pointed out, the issue is that your input buffer had a string for the number AND a newline. C++ I/O skips leading whitespace when it reads something like a number out, but it doesn’t take the trailing whitespace out of the buffer. It leaves that for the next read to deal with. So
getchar()is getting that newline that’s still pending.Ignore advice from people who are trying to tell you to flush(), ignore(), or clear out “whatever was in the buffer before the
getchar()call”. These functions have no notions of “non-blocking” input.Said another way: the usual C++ input stream functions don’t have a concept of “there’s nothing there right now”…but then you call later and it says “oh, but now there’s something!!!” There’s an “input sequence” that you can only detect as stopping when you hit EOF.
The exception to this would be readsome()…which rather than operating on an “input sequence” operates on the “input buffer”. Finding such a thing, we might try this:
But at least on my machine, it doesn’t lead to the desired effect. Which means that even though there’s a newline sitting in the terminal app or OS pipeline somewhere, it hasn’t yet gotten as far as the internal stream buffer object for
cin. Upshot is: there is a non-blocking input function based on the buffer, but in this kind of scenario it apparently isn’t going to help.The real answer is what Alf said in the comment. Most decent dev environments or setups will have some way to configure it to not let the console close automatically. If not, hack around it with your launch method. Heck, you can even put a breakpoint on the
return 0in main!Notes:
You should be aware that “correct” C++ inclusions of compatibility libraries for C are done as
#include <cfoo>instead of#include "foo.h". It may not make all that big a difference in practice…but at minimum it distracts from your question when people comment about it (like I’m doing right now):Is it bad practice to use a C header instead of its C++ equivalent in C++ (e.g. stdio.h instead of cstdio)?
Also, you could have demonstrated this with a much smaller sample! You could have shown the effect simply with:
So try and pare down your examples to really isolate the problem in the future! (Feel free to edit your question to be this succinct in order to make this thread more useful for people searching.)